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

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

by Yuriy Tymchuk

On 11 Feb 2014, at 17:12, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 11 Feb 2014, at 16:51, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>>> 4. Preferences persistence. >>>> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >>>> easy - advanced >>>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> >>> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. >> >> Did you implement it? > > I did, months ago :) > > Ben 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. Uko > >> >> Uko >> >>> >>> Ben >>> >> >

Feb. 11, 2014

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

by Esteban Lorenzano

On 11 Feb 2014, at 17:12, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On 11 Feb 2014, at 16:51, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> >> On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>>> 4. Preferences persistence. >>>> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >>>> easy - advanced >>>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> >>> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. >> >> Did you implement it? > > I did, months ago :) year(s) ago, in fact :) > > Ben > >> >> Uko >> >>> >>> Ben >>> >> >

Feb. 11, 2014

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

by Benjamin

On 11 Feb 2014, at 16:51, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >>> 4. Preferences persistence. >>> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >>> easy - advanced >>> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> >> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. > > Did you implement it? I did, months ago :) Ben > > Uko > >> >> Ben >> >

Feb. 11, 2014

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

by Yuriy Tymchuk

On 11 Feb 2014, at 16:49, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> 4. Preferences persistence. >> Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. >> easy - advanced >> Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > > In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. Did you implement it? Uko > > Ben >

Feb. 11, 2014

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

by Benjamin

> 4. Preferences persistence. > Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. > easy - advanced > Yuriy Tymchuk <yuriy.tymchuk(a)me.com> In Settings there is a button Export which (should) export all you settings into your preferences file and therefore be spread among images. Ben

Feb. 11, 2014

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

by Igor Stasenko

On 11 February 2014 10:07, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hi Igor and all! > > On 02/10/2014 11:56 PM, Igor Stasenko wrote: > [SNIP] > > Just to give you +1 on the Smalltalk family part. I mean, hell, >> we even share the VM! >> >> And I am not sure people understand how important this has been >> for us Squeak/Pharooners, AFAIK a LOT of the work from Eliot has >> been done through Newspeakish money, right? >> >> >> Yes. I've worked for Cadence twice. Once in 2007 to 2008 where I >> first worked on the Squeak interpreter and added immutability. Form >> there, now familiar with VMMaker I went to Qwaq and got to create >> Cog. I'm now back at Cadence and able to continue to work on Cog. >> In particular, Spur has only been possible because of my boss at >> Cadence, Yaron Kashai. At Cadence we're using Newspeak to implement >> systems for SoaC integration. Without Newspeak there would be no >> Spur. WIthout Newspeak the Cog VM would not be nearly as developed >> or reliable. >> >> I don't want to stoke the flames but I do hope that the community >> will consider Newspeak as part of the Smalltalk family. It is >> definitely a blood relative. Don't treat it like a black sheep. >> >> >> I am not arguing whether Newspeak belongs to smalltalk family or not >> (clearly it is). >> The point is that 'S' letter in ESUG stands for Smalltalk, not Newspeak. >> (else we should be naming it properly - ENUG). >> So, the question is whether any non-smalltalk project is eligible to run >> and compete (because there is limited number of slots) with smalltalk >> projects under ESUG umbrella? >> > > Well, first of all I was actually *not* talking about that particular > incident (whatever took place, I have no idea) - my mistake to not make > that clear - I merely wanted to note that we should stick together as a > family *in general*. Gilad should really feel that IMHO. > > Nevertheless just like Dennis noted - Pharo doesn't start with an "S" - > hell, it even uses the phrase "Smalltalk inspired" to distance itself and > make clear that hey, this is not a Smalltalk! > > And Pharo has Traits so is it "Smalltalk"? :) Amber doesn't even have > globals (!) so is Amber "a Smalltalk"? > > And the fact that Newspeak actually *shares the VM* with Pharo and Squeak > - that indicates a pretty strong connection, don't you think? Much stronger > than Amber many would argue... And oh, Amber actually *claims* to be a > Smalltalk ;) On the other hand it wants to be compatible with Pharo which > claims to be only "inspired"... oh, darnit! > > Just kidding (well, 50% serious perhaps) Igor, I get what you mean, just > getting a bit philosophical here, I haven't had my morning coffee... :) > > Nothing philosophical here. Pharo, Amber are smalltalk dialects. Newspeak is not. It is brand new language. Different syntax, different semantics. The fact that it uses VM which can run smalltalk doesn't makes any difference. There's a number of Smalltalks impemented on top of JVM, and CLR platforms. Following your logic, then such implementations should be eligible to run under 'java/C# GSoC umbrella'? And let me be clear: i am not against Newspeak or any other language or person(s) who invested a lot into it and keep investing. They are doing good things in exploring and pushing forward original ideas and enriching our computing world. But as to me it is clear example, where ESUG should draw a line. -- Best regards, Igor Stasenko.

Feb. 11, 2014

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

by Yuriy Tymchuk

Hey guys. 1. Implicit variable declarations support in FAST Make FAST to work with one of the languages that do not have explicit declaration of variables. Preferable target language is Javascript. This should move FAST to new horizons. advanced Yuriy Tymchuk <yuriy.tymchuk(a)me.com>, Anne Etien <anne.etien(a)univ-lille1.fr> 2. Interaction API for Roassal. Provide a nice api of Roassal to filter, select, delete, groupâ¦ etc elements. This will be extra useful for reverse engineering tools. advanced - complex Alexandre Bergel <alexandre.bergel(a)me.com>, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 3. Tools to work with resources (non-text data). Even if serialising it as code is not a good solution we can make tools to load, serialise resources to codeâ¦ easy - advanced Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 4. Preferences persistence. Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. easy - advanced Yuriy Tymchuk <yuriy.tymchuk(a)me.com> Cheers Uko On 11 Feb 2014, at 10:42, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi fellow Pharo hackers, > > ESUG, the European Smalltalk User Group, is applying for this > year's Google Summer of Code. As you probably know, the Summer > of Code provides the opportunity to fund students to work during > the summer on Pharo. Please reply to this > email (be sure to use "Reply to all") if you have ideas you > would like to propose. > > Please include a summary of the project and links to web pages > that can help prospective students to write their application. > Please also include the following information: > > - if applicable, other dialects that you would be willing to > mentor this project for > > - the skill level > > - name of the mentor(s), email addresses, and possibly any IRC > network/channel/nickname where they can be found. > > Thanks for contributing to ESUG's Summer of Code application! > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Feb. 11, 2014

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

by Yuriy Tymchuk

Hey guys. 1. Implicit variable declarations support in FAST Make FAST to work with one of the languages that do not have explicit declaration of variables. Preferable target language is Javascript. This should move FAST to new horizons. advanced Yuriy Tymchuk <yuriy.tymchuk(a)me.com>, Anne Etien <anne.etien(a)univ-lille1.fr> 2. Interaction API for Roassal. Provide a nice api of Roassal to filter, select, delete, groupâ¦ etc elements. This will be extra useful for reverse engineering tools. advanced - complex Alexandre Bergel <alexandre.bergel(a)me.com>, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 3. Tools to work with resources (non-text data). Even if serialising it as code is not a good solution we can make tools to load, serialise resources to codeâ¦ easy - advanced Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 4. Preferences persistence. Now prefs are only working while you are on the same image. We can put a button: save for all images, and serialise prefs to conf. folder when this button is checked. The same goes for user name. Why not to put checkbox: âSave for all next imagesâ. This way we wonât have a lot of clones in monticello and make userâs life easier. You can use a startup scripts, but this is not cool. easy - advanced Yuriy Tymchuk <yuriy.tymchuk(a)me.com> Cheers Uko On 11 Feb 2014, at 10:42, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi fellow Pharo hackers, > > ESUG, the European Smalltalk User Group, is applying for this > year's Google Summer of Code. As you probably know, the Summer > of Code provides the opportunity to fund students to work during > the summer on Pharo. Please reply to this > email (be sure to use "Reply to all") if you have ideas you > would like to propose. > > Please include a summary of the project and links to web pages > that can help prospective students to write their application. > Please also include the following information: > > - if applicable, other dialects that you would be willing to > mentor this project for > > - the skill level > > - name of the mentor(s), email addresses, and possibly any IRC > network/channel/nickname where they can be found. > > Thanks for contributing to ESUG's Summer of Code application! > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

Feb. 11, 2014

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

by Igor Stasenko

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. > > (replying Goran) Depends what you calling base libraries. Kernel, basic I/O is clean of it , and there's good reasons for keeping things that way. And because i know how painful it can be to maintain custom assembler code, i would never use it if i could have better alternative. Oh.. what i trying to prove: i just using it because i can :P But it is of course for projects which under my direct control.. i didn't rewrote random parts of Pharo with assembler code.. and never will. :) -- Best regards, Igor Stasenko.

Feb. 11, 2014

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

by Igor Stasenko

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. Doing anything before that is just waste of time. -- Best regards, Igor Stasenko.

Feb. 11, 2014