- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Use pharo users mailing list

by kilon

The one I found curious is that when I go to "smalltalk" tag http://stackoverflow.com/questions/tagged/pharo+smalltalk <http://stackoverflow.com/questions/tagged/pharo+smalltalk> Almost all questions for smalltalk are about pharo. Are we by any chance more popular than we think ? :D Or maybe smalltalkers by large don't like stackoverflow. Its strange though. philippeback wrote > Google and a copy of the list in there is fine enough for me. > > SO is okay but frankly, I do not go there to look for stuff/answer > questions, but because my google search sends me there. > > Where we could have exposure would be on things like infoQ. > > Regards, > --- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail: > phil@ > | Web: http://philippeback.eu > Blog: http://philippeback.be | Twitter: @philippeback > Youtube: http://www.youtube.com/user/philippeback/videos > > High Octane SPRL > rue cour Boisacq 101 | 1301 Bierges | Belgium > > Pharo Consortium Member - http://consortium.pharo.org/ > Featured on the Software Process and Measurement Cast - > http://spamcast.libsyn.com > Sparx Systems Enterprise Architect and Ability Engineering EADocX Value > Added Reseller > > > > > On Mon, Sep 23, 2013 at 2:33 PM, Esteban A. Maringolo > < > emaringolo@ > >wrote: > >> The difference not only lies in the format, but also in the user base. >> >> I'm 30+ years old, and I grew up using bulletin boards, newsgroups and >> mailing list, but there is a big generation of "programmers" (emphasis >> in the quotes) that will never subscribe to a mailing list, some don't >> even know what a mailing list is. They grew up using sites like Yahoo >> Answers, and expect the same for their programming questions. >> >> I guess it is the same that happened in the transition from newsgroups >> to mailing lists, and as in the bbc to newsgroups, and newsgroups to >> mailing lists, every new generation seems to me like an order of >> magnitude bigger. >> >> I think BOTH options are okay, it is, a user list and StackOverflow >> like websites. The SEO of the later is really good. >> The flattening of the question/answer curve may have to do with the >> fact that most questions have been answered and they start to repeat. >> >> I use StackOverflow and SuperUser on a daily basis. And I do find most >> of the answers I need. >> >> To me the radical choice would be to merge both users and development >> mailing lists. >> The separation is okay from an organization point of view, but the >> volume today is no that big as to justify fragmentation, seems like an >> "early optimization". >> >> Regards, >> >> >> Esteban A. Maringolo >> >> >> 2013/9/23 H. Hirzel < > hannes.hirzel@ > >: >> > On 9/23/13, Stephan Eggermont < > stephan@ > > wrote: >> >> Kilon wrote >> >>>Here is a radical suggestion you probably don't want to hear. >> >>>Close down Pharo users mailing list, redirect everyone to >> stackoverflow. >> >> >> >> Definitely not. Stackoverflow is nearly dead, and seriously unsuitable >> for >> >> small languages. >> > >> > There are obstacles but one cannot say that it is "seriously >> > unsuitable". Stackoverflow question demand a certain format, typically >> > something like >> > >> > - statement of what you want to accomplish >> > - attempt a solution with code which has problems >> > - question >> > >> >>Good questions will get closed by clueless people. >> > Mostly if the form does not fit. >> > And if there are Pharo people (maybe earned in another area) with >> > enough reputation points this may be prevented >> > >> >> Good answers will get downvoted because they go against majority >> >> views. >> > >> > Why? >> > >> >>The ranking system is heavily skewed towards popular languages. >> > >> > It is based on the number of hits which is naturally less in less >> > popular languages. >> > However subcommunities may function well in stackoverflow. >> > >> > the tagging and referencing system is excellent. >> > >> >> Stackoverflow doesn't allow discussions (and interesting questions), >> > >> > No, but that is not the aim of the site. It is a question and answer >> > site for _coding_ and maybe _design_ problems to a certain extent. >> > >> > However it allows for wiki pages. Any answer may be turned into a wiki >> page. >> > >> >> which is a major reason to have these lists. >> > >> > List are good in addition. >> > >> > --Hannes >> > >> >> To see for yourself, take a look at the questions related to OODBs. >> >> >> >> Stephan >> >> >> >> >> > >> >> -- View this message in context: http://forum.world.st/Use-pharo-users-mailing-list-tp4709698p4709785.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 23, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Frank Shearar

On 23 September 2013 14:34, Max Leske <maxleske(a)gmail.com> wrote: > > On 23.09.2013, at 15:20, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 23 September 2013 14:17, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> Here is my 100% personal opinion: >>> >>> I don't like the copyShuffle. >>> To me, the rules are quite clear: >>> sort shuffle reverse etc... -> perform modification in place >>> sorted shuffled reversed etc... -> answer a copy >>> I hope the methods comments are clear. Does PBE tells about these >>> conventions? It would be a good thing. >>> >>> And I don't like to have mutexes in base library, the less we have, the >>> better. >>> If a user is going to modify the same object concurrently, he/she takes care >>> of mutual exclusion. >> >> Especially since locks don't compose. If you _really_ cared about >> accessing something concurrently, you'd share immutable data >> structures. > > I don't quite follow. Could you elaborate? Hopefully it's uncontroversial to assert that locks don't compose. If you only ever have one thread of execution, you don't have any concurrency issues, and locks serve no purpose. If you do have multiple threads of execution, then you have a few choices for sharing data: * you can use a lock around mutable data (but lock-using blocks of code don't compose, so you end up with loads of bugs or deadlocks or nests of locks, or all of the above) * you can share a _copy_ of data. In the latter case, you can share an actual copy, or share a pointer to a structure that can't change. If it can't change, you can't have a reader accidentally reading something from a structure halfway through the writer writing to it. Sharing some immutable chunk of state lets you save the memory taken up by a copy, but also prevents all the race condition things you usually get with shared mutable state. frank >> frank >> >>> 2013/9/23 Max Leske <maxleske(a)gmail.com> >>>> >>>> Sven suggested posting this on the list for discussion, so here you go: >>>> >>>> Maybe this should be discussed on the list, your are going to break API. >>>> >>>> Note that there is also #sort and #sorted with similar copy behavior. >>>> >>>> Also, I am not sure that basic operations should use mutexes to protect >>>> themselves by default: there is a cost when you are a single threaded user. >>>> Even in Java there are synchronized and non-synchronized versions of >>>> collections. IMHO, the protection should happen in your app, and basic >>>> collections do not have to be thread safe. >>>> >>>> Sven >>>> >>>> #shuffle does not use Collection>>mutexForPicking as other users of >>>> #randomForPicking demonstrate. This can lead to race conditions (found in >>>> our application). >>>> >>>> In addition, there are now #shuffle, #shuffled, #shuffleBy: and >>>> #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers >>>> that. This is very confusing. >>>> >>>> I propose a fix where #shuffled and #shuffledBy: are renamed to >>>> #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. >>>> #shuffle and #copyShuffle will use the mutex to prevent race conditions. >>> >>> >> > >

Sept. 23, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Max Leske

On 23.09.2013, at 15:20, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 23 September 2013 14:17, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Here is my 100% personal opinion: >> >> I don't like the copyShuffle. >> To me, the rules are quite clear: >> sort shuffle reverse etc... -> perform modification in place >> sorted shuffled reversed etc... -> answer a copy >> I hope the methods comments are clear. Does PBE tells about these >> conventions? It would be a good thing. >> >> And I don't like to have mutexes in base library, the less we have, the >> better. >> If a user is going to modify the same object concurrently, he/she takes care >> of mutual exclusion. > > Especially since locks don't compose. If you _really_ cared about > accessing something concurrently, you'd share immutable data > structures. I don't quite follow. Could you elaborate? > > frank > >> 2013/9/23 Max Leske <maxleske(a)gmail.com> >>> >>> Sven suggested posting this on the list for discussion, so here you go: >>> >>> Maybe this should be discussed on the list, your are going to break API. >>> >>> Note that there is also #sort and #sorted with similar copy behavior. >>> >>> Also, I am not sure that basic operations should use mutexes to protect >>> themselves by default: there is a cost when you are a single threaded user. >>> Even in Java there are synchronized and non-synchronized versions of >>> collections. IMHO, the protection should happen in your app, and basic >>> collections do not have to be thread safe. >>> >>> Sven >>> >>> #shuffle does not use Collection>>mutexForPicking as other users of >>> #randomForPicking demonstrate. This can lead to race conditions (found in >>> our application). >>> >>> In addition, there are now #shuffle, #shuffled, #shuffleBy: and >>> #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers >>> that. This is very confusing. >>> >>> I propose a fix where #shuffled and #shuffledBy: are renamed to >>> #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. >>> #shuffle and #copyShuffle will use the mutex to prevent race conditions. >> >> >

Sept. 23, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Max Leske

On 23.09.2013, at 15:17, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Here is my 100% personal opinion: > > I don't like the copyShuffle. Me neither :) But see below. > To me, the rules are quite clear: > sort shuffle reverse etc... -> perform modification in place agreed. > sorted shuffled reversed etc... -> answer a copy If you're aware that this convention exists, then ok. BUT: I've been working with Pharo for over 4 years now and I wasn't aware of it. Since we want to make Pharo accessible to new users it is my oppinion that this convention isn't a good one. Especially since messages that answer a copy usually are named #copyXXX. To me, there is no semantical difference between #shuffle and #shuffled, the message names are not revealing in this case (again: personal oppion). > I hope the methods comments are clear. Does PBE tells about these conventions? It would be a good thing. > > And I don't like to have mutexes in base library, the less we have, the better. > If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. Agreed. BUT: the Random object used by these methods is the same one that is used by #atRandom for instance, hence the race condition. There is no way anyone can safely use these methods without the mutex, single threaded or not. Calls to methods using that same Random object can be all over the place and also in the base system. > > > 2013/9/23 Max Leske <maxleske(a)gmail.com> > Sven suggested posting this on the list for discussion, so here you go: > >> Maybe this should be discussed on the list, your are going to break API. >> >> Note that there is also #sort and #sorted with similar copy behavior. >> >> Also, I am not sure that basic operations should use mutexes to protect themselves by default: there is a cost when you are a single threaded user. Even in Java there are synchronized and non-synchronized versions of collections. IMHO, the protection should happen in your app, and basic collections do not have to be thread safe. >> >> Sven >> >>> #shuffle does not use Collection>>mutexForPicking as other users of #randomForPicking demonstrate. This can lead to race conditions (found in our application). >>> >>> In addition, there are now #shuffle, #shuffled, #shuffleBy: and #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers that. This is very confusing. >>> >>> I propose a fix where #shuffled and #shuffledBy: are renamed to #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. #shuffle and #copyShuffle will use the mutex to prevent race conditions. >

Sept. 23, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Frank Shearar

On 23 September 2013 14:17, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Here is my 100% personal opinion: > > I don't like the copyShuffle. > To me, the rules are quite clear: > sort shuffle reverse etc... -> perform modification in place > sorted shuffled reversed etc... -> answer a copy > I hope the methods comments are clear. Does PBE tells about these > conventions? It would be a good thing. > > And I don't like to have mutexes in base library, the less we have, the > better. > If a user is going to modify the same object concurrently, he/she takes care > of mutual exclusion. Especially since locks don't compose. If you _really_ cared about accessing something concurrently, you'd share immutable data structures. frank > 2013/9/23 Max Leske <maxleske(a)gmail.com> >> >> Sven suggested posting this on the list for discussion, so here you go: >> >> Maybe this should be discussed on the list, your are going to break API. >> >> Note that there is also #sort and #sorted with similar copy behavior. >> >> Also, I am not sure that basic operations should use mutexes to protect >> themselves by default: there is a cost when you are a single threaded user. >> Even in Java there are synchronized and non-synchronized versions of >> collections. IMHO, the protection should happen in your app, and basic >> collections do not have to be thread safe. >> >> Sven >> >> #shuffle does not use Collection>>mutexForPicking as other users of >> #randomForPicking demonstrate. This can lead to race conditions (found in >> our application). >> >> In addition, there are now #shuffle, #shuffled, #shuffleBy: and >> #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers >> that. This is very confusing. >> >> I propose a fix where #shuffled and #shuffledBy: are renamed to >> #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. >> #shuffle and #copyShuffle will use the mutex to prevent race conditions. > >

Sept. 23, 2013

Re: [Pharo-dev] 11635: Race condition in SequenceableCollection>>shuffle

by Nicolas Cellier

Here is my 100% personal opinion: I don't like the copyShuffle. To me, the rules are quite clear: sort shuffle reverse etc... -> perform modification in place sorted shuffled reversed etc... -> answer a copy I hope the methods comments are clear. Does PBE tells about these conventions? It would be a good thing. And I don't like to have mutexes in base library, the less we have, the better. If a user is going to modify the same object concurrently, he/she takes care of mutual exclusion. 2013/9/23 Max Leske <maxleske(a)gmail.com> > Sven suggested posting this on the list for discussion, so here you go: > > Maybe this should be discussed on the list, your are going to break API. > > Note that there is also #sort and #sorted with similar copy behavior. > > Also, I am not sure that basic operations should use mutexes to protect > themselves by default: there is a cost when you are a single threaded user. > Even in Java there are synchronized and non-synchronized versions of > collections. IMHO, the protection should happen in your app, and basic > collections do not have to be thread safe. > > Sven > > #shuffle does not use Collection>>mutexForPicking as other users of > #randomForPicking demonstrate. This can lead to race conditions (found in > our application). > > In addition, there are now #shuffle, #shuffled, #shuffleBy: and > #shuffledBy: where #shuffled and #shuffledBy: shuffle a copy and answers > that. This is very confusing. > > I propose a fix where #shuffled and #shuffledBy: are renamed to > #copyShuffle and #copyShuffledBy: and moved to the "copying" protocol. > #shuffle and #copyShuffle will use the mutex to prevent race conditions. > >

Sept. 23, 2013

Re: [Pharo-dev] Extending HelpTopic

by StÃ©phane Ducasse

On Sep 23, 2013, at 2:41 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > No no no I am not discouraged far from it, just not familiar with the > process. For example I had no clue that multiple slices were encouraged, > even ones that are WIP. That definetly changes everything. > > I would love to hear you workflow on this one, for example do you also > commit your own changes to smalltalkhub for backup ? a slice is just a bunch of packages but this is important for us to know which packages work with which other ones. > Also whats the diffirence between a slice and a regular commit ? Why you advise people not > to save the image with their changes (I assume its for testing the slice ) ? > > I would love to contribute to pharo , I really like this community cause has > been more than friendly to me and I love pharo of course since you seem to > have very similar goal to what I want to achieve with coding. I started a > project on visual live coding in python to find out that pharo was doing > already more than I was dreaming of and I left python to code for pharo . > Now my project is just to enhance pharo here and there, clean up morphic, > create a cool gui that will be easy to use, a nice help system (with > documentation of course) and an app/ library store similarly to the Apple > app store (but of course free). If some of those ideas can be integrated > inside pharo and the community wants them so much the better for me. I also > don't mind fixing the occasional bug (not my bugs, I never make bugs only > "weird" features :D ). > > Also if I can submit my slices , continue to work and resubmit any future > slices thats great for me. The problem was never waiting for a review and > integration :) I just did not want to be stopped from working because I was > waiting for a review. If I can submit multiple slices then no problemo. yes > > > EstebanLM wrote >> please, do not take it as a disincentive to collaborate, this should be >> quite the opposite :) >> >> I was trying to ask for some patience because when you join into a >> collaborative community, obviously the times spent on "the process" will >> be different than if you work alone. The gain is obvious, but we often >> lose from mind the price to pay (you do not control all the stages of the >> process). >> >> So, if you submit something, it will be some time to get the feedback >> (time to people to notice your change, to see it, etc.). Also, I was not >> talking about Marcus, Stef or me... since we are not the reviewers (that's >> also a responsibility of everybody in the community): we are just the >> integrators. >> >> So please, continue committing changes to the process... the review will >> come :) >> >> btw... one thing that I usually do when working: I commit slices even if >> they are not ready. Then I continue submitting slices until work is >> done... then I move the fix to "review needed". That way you can work in >> big changes and also be preparing a SLICE for the right moment. >> >> cheers, >> Esteban >> >> >> On Sep 23, 2013, at 11:19 AM, kilon < > >> thekilon@.co > >> > wrote: >> >>> EstebanLM wrote >>>> also, putting your code in "review needed" would help to reviewers to >>>> notice that you submitted something :) >>>> >>>> On Sep 23, 2013, at 11:07 AM, Esteban Lorenzano < >>> >>>> estebanlm@ >>> >>>> > wrote: >>>> >>>>> you submitted yesterday... a sunday... and we have a not so big >>>>> community, and all of us has a lot of tasks and things to do. >>>>> you should be a bit more patient :) >>>>> >>>>> Esteban >>>>> >>>>> On Sep 23, 2013, at 10:56 AM, kilon < >>> >>>> thekilon@.co >>> >>>> > wrote: >>>>> >>>>>> I take it from the silence , there is no interest in my code :D >>>>>> >>>>>> That's fine I will create my own HelpTopic class and keep it >>>>>> independent >>>>>> from pharo internal libs so I dont have to bother people with slices >>>>>> they >>>>>> don't deem important :) Makes my life easier too ;) >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/Extending-HelpTopic-tp4709645p4709730.html >>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>> Nabble.com. >>>>>> >>>>> >>> >>> No problemo this is why I submitted this slice to see how the overall >>> process work and gain some experience so when the time comes to fix a >>> pharo >>> bug I can do it properly. >>> >>> yeah this is why I decided to keep code bases separate. I don't see a >>> need >>> for me to wait so long for a review to my code cause I will want to move >>> on >>> eventually. And plus I create more work for you and as you said there too >>> few of you and you already very busy. And I totally understand that and I >>> am >>> here to make your life easier and not harder ;) >>> >>> So its no problem I will continue the effort alone, and ping this list >>> back >>> when I have something substantial to show. >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Extending-HelpTopic-tp4709645p4709735.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> > > > > > > -- > View this message in context: http://forum.world.st/Extending-HelpTopic-tp4709645p4709763.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 23, 2013

Re: [Pharo-dev] Integration Process

by Camillo Bruni

On 2013-09-23, at 05:00, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 23 Sep 2013, at 06:21, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Plus I made an 8 minute screencast with all the details of the integration:https://vimeo.com/75183993 > > Very nice, thank you ! > > This should be posted on some webpage somewhere, not be hidden on the mailing list. yes, I will put a link on the wiki page. Maybe on the pharo screen cast? > Of course, the 'Camillo Bruni Coding Speed' might be a bit too intimidating ;-) :P, yet it takes 7 minutes to explain all the details :(

Sept. 23, 2013

Re: [Pharo-dev] [Pharo-users] [ANN] Launching Pharo on Ubuntu

by Erwan Douaille

Thanks :) 2013/9/23 Camillo Bruni <camillobruni(a)gmail.com> > good work! > > On 2013-09-23, at 09:13, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > > For Ubuntu users who are using my PPA > > (https://launchpad.net/~pharo/+archive/stable/) you can now launch > > Pharo from either the Ubuntu Dashboard or the terminal (just type > > 'pharo'). > > > > In both cases, you will see the Pharo Launcher from which you can > > create new images from templates on the web and launch existing > > images. http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher > > > > No need for manual download of zip files, unpacking, and directory > > management. The launcher does everything for you. > > > > Have fun > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." > > Winston Churchill > > <pharo-launcher-screenshot.png> > > -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Sept. 23, 2013

Re: [Pharo-dev] Extending HelpTopic

by kilon

No no no I am not discouraged far from it, just not familiar with the process. For example I had no clue that multiple slices were encouraged, even ones that are WIP. That definetly changes everything. I would love to hear you workflow on this one, for example do you also commit your own changes to smalltalkhub for backup ? Also whats the diffirence between a slice and a regular commit ? Why you advise people not to save the image with their changes (I assume its for testing the slice ) ? I would love to contribute to pharo , I really like this community cause has been more than friendly to me and I love pharo of course since you seem to have very similar goal to what I want to achieve with coding. I started a project on visual live coding in python to find out that pharo was doing already more than I was dreaming of and I left python to code for pharo . Now my project is just to enhance pharo here and there, clean up morphic, create a cool gui that will be easy to use, a nice help system (with documentation of course) and an app/ library store similarly to the Apple app store (but of course free). If some of those ideas can be integrated inside pharo and the community wants them so much the better for me. I also don't mind fixing the occasional bug (not my bugs, I never make bugs only "weird" features :D ). Also if I can submit my slices , continue to work and resubmit any future slices thats great for me. The problem was never waiting for a review and integration :) I just did not want to be stopped from working because I was waiting for a review. If I can submit multiple slices then no problemo. EstebanLM wrote > please, do not take it as a disincentive to collaborate, this should be > quite the opposite :) > > I was trying to ask for some patience because when you join into a > collaborative community, obviously the times spent on "the process" will > be different than if you work alone. The gain is obvious, but we often > lose from mind the price to pay (you do not control all the stages of the > process). > > So, if you submit something, it will be some time to get the feedback > (time to people to notice your change, to see it, etc.). Also, I was not > talking about Marcus, Stef or me... since we are not the reviewers (that's > also a responsibility of everybody in the community): we are just the > integrators. > > So please, continue committing changes to the process... the review will > come :) > > btw... one thing that I usually do when working: I commit slices even if > they are not ready. Then I continue submitting slices until work is > done... then I move the fix to "review needed". That way you can work in > big changes and also be preparing a SLICE for the right moment. > > cheers, > Esteban > > > On Sep 23, 2013, at 11:19 AM, kilon < > thekilon@.co > > wrote: > >> EstebanLM wrote >>> also, putting your code in "review needed" would help to reviewers to >>> notice that you submitted something :) >>> >>> On Sep 23, 2013, at 11:07 AM, Esteban Lorenzano < >> >>> estebanlm@ >> >>> > wrote: >>> >>>> you submitted yesterday... a sunday... and we have a not so big >>>> community, and all of us has a lot of tasks and things to do. >>>> you should be a bit more patient :) >>>> >>>> Esteban >>>> >>>> On Sep 23, 2013, at 10:56 AM, kilon < >> >>> thekilon@.co >> >>> > wrote: >>>> >>>>> I take it from the silence , there is no interest in my code :D >>>>> >>>>> That's fine I will create my own HelpTopic class and keep it >>>>> independent >>>>> from pharo internal libs so I dont have to bother people with slices >>>>> they >>>>> don't deem important :) Makes my life easier too ;) >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Extending-HelpTopic-tp4709645p4709730.html >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>> Nabble.com. >>>>> >>>> >> >> No problemo this is why I submitted this slice to see how the overall >> process work and gain some experience so when the time comes to fix a >> pharo >> bug I can do it properly. >> >> yeah this is why I decided to keep code bases separate. I don't see a >> need >> for me to wait so long for a review to my code cause I will want to move >> on >> eventually. And plus I create more work for you and as you said there too >> few of you and you already very busy. And I totally understand that and I >> am >> here to make your life easier and not harder ;) >> >> So its no problem I will continue the effort alone, and ping this list >> back >> when I have something substantial to show. >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Extending-HelpTopic-tp4709645p4709735.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/Extending-HelpTopic-tp4709645p4709763.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 23, 2013