Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
August 2016
- 766 messages
websockets in pharo?
by Tudor Girba
Hi,
Can anyone tell me if there is a Websocket implementation for Pharo?
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"From an abstract enough point of view, any two things are similar."
Aug. 24, 2016
Re: [Pharo-dev] Having fun with Pharo
by webwarrior
Aliaksei Syrel wrote
> Hi
>
> Did you know that `2 * 10.2` is two times slower than `2 asFloat * 10.2`?
>
> Here is performance test (inspect result, takes ~10s to complete):
> http://ws.stfx.eu/4T0CR23OURZW
>
> Who knows how performance can be improved with this knowledge...
>
> Cheers,
> Alex
And on pre-Spur VM it's like 6 or 7 times slower.
More interesting fact is that (float * int) gets optimized, but (int *
float) doesn't.
It would be cool to have an up-to-date document explaining preformance
characteristics of Pharo code and optimizations done by compiler/JIT.
Right now only source of such stuff seems to be the blog of Clément Béra
(https://clementbera.wordpress.com/)
--
View this message in context: http://forum.world.st/Having-fun-with-Pharo-tp4912104p4912472.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Aug. 24, 2016
Call for Papers: Object Oriented Programming Languages and Systems @ SAC 2017, April 3-7, 2017
by Nick Papoylias
**************************************************
OOPS 2017 Call for Papers
Object-Oriented Programming Languages and Systems
http://oops.disi.unige.it/OOPS17
**************************************************
Technical Track at the 32nd ACM Symposium on Applied Computing, SAC 2017
http://www.acm.org/conferences/sac/sac2017
April 3 - 7, 2017
Marrakesh, Morocco
- Important Dates
Submission of regular papers and SRC abstracts
September 15, 2016
Paper and SRC notifications
November 10, 2016
Paper and SRC camera-ready copies
November 25, 2016
Author registration
December 10, 2016
SAC 2017
April 3 - 7, 2017
- Track Chair
Davide Ancona (davide.ancona(a)unige.it)
DIBRIS, University of Genova, Italy
- SAC 2017
For the past thirty one years, the ACM Symposium on Applied Computing (SAC)
has been a
primary gathering forum for applied computer scientists, computer
engineers, software
engineers, and application developers from around the world.
SAC 2017 is sponsored by the ACM Special Interest Group on Applied
Computing (SIGAPP) and
is hosted by the University of Quebec at Montreal, Canada; University Cadi
Ayyad (UCA) of
Marrakech, Morocco; National School of Engineering in Rabat (EMI), Rabat,
Morocco; and
National School of Applied Sciences (ENSA) of Kenitra, Morocco.
- Call For Student Research Abstracts
Graduate students seeking feedback from the scientific community on their
research ideas
are invited to submit original abstracts of their research work in areas of
experimental
computing and application development related to SAC 2017 Tracks. The
Student Research
Competition (SRC) Program is designed to provide graduate students the
opportunity to meet
and exchange ideas with researchers and practitioners in their areas of
interest.
- OOPS Track: Aims and Topics
Object-oriented programming (OOP) has become the mainstream programming
paradigm for
developing complex software systems in most application domains.
However, existing OO languages and platforms need to evolve to meet the
continuous demand
for new abstractions, features, and tools able to reduce the time, effort,
and cost of
creating object-oriented software systems, and improving their performance,
quality and
usability.
To this aim, OOPS is seeking for research advances bringing benefits in all
those typical
aspects of software development, such as modeling, prototyping, design,
implementation,
concurrency and distribution, code generation, analysis, verification,
testing, debugging,
evaluation, deployment, maintenance, reuse, and software evolution and
adaptation.
The specific topics of interest for the OOPS track include, but are not
limited to, the
following:
* Aspects and components
* Code generation, and optimization, just-in-time compilation
* Context-oriented programming
* Databases and persistence
* Distribution and concurrency
* Dynamic and scripting languages
* Evaluation
* Feature Oriented Software Development and Programming
* Formal verification
* Internet of Things technology and programming
* Integration with other paradigms
* Interoperability, versioning and software evolution and adaptation
* Language design and implementation
* Modular and generic programming
* Reflection, meta-programming
* Runtime verification
* Secure and dependable software
* Static analysis
* Testing and debugging
* Type systems and type inference
* Virtual machines
OOPS offers a great opportunity to the OOP community to gain visibility,
and to
exploit the inter-disciplinary nature of SAC.
- Submission Instructions
Prospective papers should be submitted to the track in pdf format using the
START
submission system for regular and SRC papers available through the SAC 2017
home page.
Submission of the same paper to multiple tracks is not allowed; all papers
should
represent original and previously unpublished works that are currently not
under review in
any conference or journal. Both basic and applied research papers are
welcome.
SAC 2017 will use double-blind reviewing; to facilitate this, author
name(s) and
institution(s) must be omitted, and references to authors' own related work
should be in
the third person.
The format of the paper must adhere to the sig-alternate style. Full papers
are limited to
6 pages with the option for up to 2 additional pages (max of 8 pages) at
extra charge (80
USD per page). Posters are limited to 3 pages with the option for up to 1
additional page
(max of 4 pages) at extra charge (80 USD). The length of the SRC abstracts
is 2 pages with
no additional pages at extra charge.
Papers that fall short the above requirements are subjected to rejection.
All papers must
be submitted by September 15, 2016. For more information please visit the
SAC 2017 home
page.
- Proceedings
Accepted papers will be published by ACM in the annual conference
proceedings. Accepted
posters will be published as extended abstracts in the same proceedings.
Paper registration is required, allowing the inclusion of the paper/poster
in the
conference proceedings. An author or a proxy attending SAC MUST present the
paper. This is
a requirement for the paper/poster to be included in the ACM/IEEE digital
library. No-show
of scheduled papers and posters will result in excluding them from the
ACM/IEEE digital
library. Student registration is only intended to encourage student
attendance and does
not cover inclusion of papers/posters in the conference proceedings.
Finally, following the tradition of the past OOPS editions, depending on
the quality and
the overall number of accepted papers, authors of selected papers will be
invited to
submit an extended version for a journal special issue, after the
conference.
Aug. 24, 2016
Re: [Pharo-dev] Refactoring HelpTopic (needs review)
by Nicolai Hess
2016-08-24 6:49 GMT+02:00 stepharo <stepharo(a)free.fr>:
> Hi nicolai
>
> I remember that I read everything and fix typos. Did you got my review or
> did I suuceed to lose it ;).
>
No, I think it was lost :-/
> Stef
>
But the helpl is now in (60192), but it is still not finished, only a
start, needs more examples and maybe better class comments.
Everyone who wants to help, just try it out
HelpBrowser openOn:RefactoringHelp
read it and give feedback.
If you find any typos, wrong or unclear information just report back, and
I'll fix it.
we need more and better docs
we need more and better docs
and it would help if we have
more and better docs :-)
>
>
> Le 6/8/16 à 15:24, Nicolai Hess a écrit :
>
>
>
> 2016-07-28 16:18 GMT+02:00 stepharo <stepharo(a)free.fr>:
>
>> I will!
>>
>> I love to read nice comments
>>
>> Stef
>>
>>
> I updated the slice and added some more example (much more is needed but I
> think it is better than having no doc :) ).
> I changed some help topics on refactoring support in nautilus to directly
> used the refactoring classes comments (no need to maintain two docs), but
> this is not applicable for all refactorings, for example "generate
> superclass" and "insert superclass" needs its own description, as there is
> only one RBAddClassRefactoring comment.
>
> please help with reviewing, I am not good at writing this kind of text.
>
> The refactoring engine is a great and powerfull piece of code and it would
> be great to have a proper documentation "in-image".
> I have seen some bugs, bad code or wrong bug fixes by contributors not
> fully understanding the framework (me too :) ).
>
> just load the slice and open
> HelpBrowser openOn: RefactoringHelp.
>
>
> thanks
> nicolai
>
>
>
>
>> Le 28/7/16 à 00:38, Nicolai Hess a écrit :
>>
>> Hi,
>>
>> I recently added some class comments to the Refactoring-Package.
>> (RBBrowserEnvironments, RBRefactoring, RBNamespace).
>>
>> Now I added some more HelpTopics describing the refactoring framework,
>> some background information, RBPatternParser and Metavariables, some
>> examples and put the existing class comments into the HelpBook.
>>
>> see fogbugz issue 18829
>> <https://pharo.fogbugz.com/f/cases/18829/Add-a-RefactoringFramework-System-H…>
>> Add a RefactoringFramework System HelpTopic
>> you can load the slice and open the HelpBook with
>>
>> HelpBrowser openOn: RefactoringHelp.
>>
>> Would be nice if someone can help with proofreading and of course, amy
>> feedback is welcome.
>>
>> nicolai
>>
>>
>>
>
>
Aug. 24, 2016
Re: [Pharo-dev] About better communication in the community
by Esteban Lorenzano
> On 24 Aug 2016, at 10:07, Gour <gour(a)atmarama.com> wrote:
>
> On Wed, 24 Aug 2016 09:38:20 +0200
> stepharo <stepharo(a)free.fr> wrote:
>
> Hello,
>
>> Looking at bugs is really difficult. There are not enough people
>> looking and fixing bugs.
>
> just a short note from a Pharo noob...it is, imho, very strange that one
> cannot even take a look at bugs *without* creating account at tracker.
>
> By having ability to, at least, skim at bugs and see if there are some
> low-hanging fruits to tackle, maybe more work could be accomplished?
>
> Having issue tracker closed for the public emits, imho, not very
> friendly signal to potential contributors.
yes, this is bad but fogbugz is a company that does issue tracking for big companies, not open source projects so they do not have this feature. You may ask then why we use them⦠is because we used to use google issue tracker and when they dropped support we needed some replacement. Long story short, none of the open issue tracker offered what we needed and fogbugz people kindly offered to give us a free account.
Now we would like to solve this problem but is hard to leave because migration is a lot of work and also (very important) because maybe fogbugz does not looks super cool, but is an *excellent* tool for tracking our issues⦠so we would need to find time to define a news process if we want to use, for example github or atlassianâ¦
cheers,
Esteban
>
>
> Sincerely,
> Gour
>
> --
> Just try to learn the truth by approaching a spiritual master.
> Inquire from him submissively and render service unto him.
> The self-realized souls can impart knowledge unto you because
> they have seen the truth.
>
>
>
Aug. 24, 2016
Re: [Pharo-dev] About better communication in the community
by Gour
On Wed, 24 Aug 2016 09:38:20 +0200
stepharo <stepharo(a)free.fr> wrote:
Hello,
> Looking at bugs is really difficult. There are not enough people
> looking and fixing bugs.
just a short note from a Pharo noob...it is, imho, very strange that one
cannot even take a look at bugs *without* creating account at tracker.
By having ability to, at least, skim at bugs and see if there are some
low-hanging fruits to tackle, maybe more work could be accomplished?
Having issue tracker closed for the public emits, imho, not very
friendly signal to potential contributors.
Sincerely,
Gour
--
Just try to learn the truth by approaching a spiritual master.
Inquire from him submissively and render service unto him.
The self-realized souls can impart knowledge unto you because
they have seen the truth.
Aug. 24, 2016
Re: [Pharo-dev] About better communication in the community
by Esteban Lorenzano
Hi,
I want to point just a couple of things:
1. You may feel hurt, but is my job to say no. If you think Iâm doing a bad job, is your right to discuss, but do not expect that what you consider a bad design decision would be shared by the board (and me as executor of board policies).
2. Features that goes inside Pharo are not decided by vote. They have to add value and share the Pharo vision (pointed in the vision document who is not slightly updated but still guides our steps). We try to reach consensus and if it is not possible, then we decide. Yes, is like that⦠Iâm sorry for not being perfect democratic but this was never the idea of Pharo (it *has* a benevolent dictator⦠who by the way is not me but a group, the board).
3. TxText vs. Twisty is a bad example (or a good example of how people can interpret things that does not know in a complete missed direction⦠our fault, this has to be communicated better)⦠what actually happened is that Igor and Denis discussed the design and they had a disagreement, but Denis shared the vision of Igor⦠just no time to wait for it because he was working pressures, so he delivered Twisty⦠I love twisty and I use it a lot in my personal projects, but this was like that⦠also, not all useful things needs to be inside Pharoâ¦
4. You have a very negative opinion about our design choices. Thatâs ok, but we are not going to remove GT just because you dislike it. What we will do is to iterate over it until we have a version that satisfies most people and hopefully you too⦠but this is like that, GT tools is our vision for the future development tools and it will stay⦠improved, of course.
Which also means that we will not accept the inclusion of alternative tools. like another workspace or browser⦠Thierry did an excellent job with his AltBrowser, and we look a lot at it to take ideas, but we will not include it either and that does not means we have a problem with him⦠What we want it more people helping us to improve the GT tools and just asking for removal does not help.
So again, I cannot stress this enough: Is my job to say no. I know I hurt some people but social development is complicated.
I do not think I do a bad job :)
cheers!
Esteban
> On 24 Aug 2016, at 09:38, stepharo <stepharo(a)free.fr> wrote:
>
> Hi Hernan
>
> First thanks for your email because we may disagree but we often agree. :) so this is an email for me.
>> Hi Stef,
>>
>> Good communication implies being clear when writing about sensitive topics, especially when communicating through virtual channels. I am not in Europe, so I cannot discuss these things with you face to face.
> This is what we want to change with montly videos meeting.
>> Therefore is not clear to me (and others) what are your policies in many subjects. Lately I also delayed the release of packages because my lack of motivation around this community, specially when discussions exists around three or fourth topics for months.
>
> Like what?
> Let us know because we do not
>> Another "motivational" case for me. I stopped to report bugs in fogbuz because I felt there was too much "Won't fix" for me (specifically by a person but I won't go there...) even in cases where it was ilogical. Then I felt tired of reading "It's like that. Invalid".
> This is a pity.
> I know the feeling because some of mine are close too. You are not the only victim of the "Issue closing syndrom" ;).
> And I would like the syndrome to be more human friendly. Thanks for raising this point.
>
> Now two points
> - You should always send a mail to the mailing-list and that we discuss your points.
>
> - Now what will happen if we all open bugs and none of us works on the open bugs.
> So what is the solution for you. I mean it concretely. How to deal with dying
>
> Looking at bugs is really difficult. There are not enough people looking and fixing bugs.
>
>> About features.
>>
>> What's the policy about voting for default features in next Pharo images? Let's suppose I am a VM/core Pharo maintainer and I want to include MySuperPackage into a Pharo release, which nobody needs (and I don't care), but it is useful to me.... there will ever be voting there? (note it doesn't makes sense if you are a group of 50 always supporting your work)
>
> It does not really work because engineers are paid for certain task.
>> Images are becoming huge (at least for my workflows). There will be (more) packages included by default (for promotion?) ?
> Thanks to raise this point because I mentioned it also to the board. So I like when I'm not alone.
> Now we should not see look only at the size. Doing nothing is size zero :)
> The point is what are the functionalities delivered.
>
> Three points:
> - what are the key things we want?
> keybinding, settings, cool inspector cool....
>
> - how many duplicated functionality can we remove:
> for example I want to merge MCDefinitions with Ring with RBDefinition
> we removed pseudo*
> but this is a lot of work
>
> The goal is to throw many system when bloc and brick are ready
>
> - what is the list of things that you would remove?
>
> - with the bootstrap and all the packages of the image managed with Cargo plus the git management
> we believe that we will be able to manage a set of images with minimal images.
> - this is several years that we are working on this goal.
> Believe me this is the vision document not for the sake of it.
>
>> How do you plan to manage if some people want the Tests be removed from the official Image? (Personally I never run them)
> - then you use a jenkins job to produce your image where you unload the tests.
>
>> Another example, what happens if another research group came with a better alternative to Calypso, Brick, Telescope, Bloc. Would you integrate first your tool to mark territory?
>
> No this is not a question of territory. Doru and GT does not do that in that spirit.
> RMOD too. We do something when we think that this is better.
> For example Epicea is three years of work of Martin, Fuel was so nice that we could not lose it.
> You see Ghost got changed by denis, Seamless got rewritten from scratch.
>
>> Who decides? For example (IIRC) TxText and Twisty.
> Igor looked at Twisty seriously and I do not think that it could handle large cobol files.
>
> (you see funnily denis is doing the same with Seamless - He rewrote it from scratch while
> nick worked on it for several years).
>
> Igor wanted to have a stream-based API that could work on modern command-oriented videos card framework.
> My team (on our own money if you understand what it means)
> paid Igor to build TxText (and I can tell you that I would have prefered him to do something else).
>
>
>> The same applies if anyone came with another rewrite of classic Smalltalk Workspace, Debugger and Inspector tools, what would you do with GT? GT stays because it came before and others would be optional?
> No this is not like that.
> If you are better or answer better needs.
>
>> There will be anything like PEPs?
> I would love but will people have the energy to implement them?
> I would definitively encourage you as a community to raise points on what you need.
>
>> If someone can answer me I think that would be an example of good communication.
> Hernan I always answered your emails. I always consider your work (and you know it for other reasons and by my facts) after I'm not always in agreement as I'm not always in agreement with other board members and this is how live happens.
> What is clear is that the most important aspects is to continue to communicate. This is why the board is launching
> this initiative and I would love to see it taken by people even for their projects.
>
>
>>
>> Hernán
>>
>>
>> 2016-08-24 1:51 GMT-03:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>:
>> Hi guys
>>
>> the board got a good discussion at ESUG about how to improve and a lot of the discussion turned around improving communication. We got some ideas that we will propose soon but I would like to get *your* ideas.
>>
>> If you have idea about improving communication around pharo please tell us.
>>
>>
>> Stef
>>
>>
>>
>
Aug. 24, 2016
[pharo-project/pharo-core] 37453d: 60192
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 37453d0fef93155634c3a198f58f01c8787d0aef
https://github.com/pharo-project/pharo-core/commit/37453d0fef93155634c3a198…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2016-08-24 (Wed, 24 Aug 2016)
Changed paths:
M AST-Core.package/RBParser.class/instance/private-parsing/parseMethod.st
M AST-Core.package/RBParser.class/instance/private-parsing/parseStatementList_into_.st
A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testInvalidPragmas.st
M AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testPragmas.st
A Collections-DoubleLinkedList.package/DoubleLink.class/README.md
A Collections-DoubleLinkedList.package/DoubleLink.class/class/instance creation/value_.st
A Collections-DoubleLinkedList.package/DoubleLink.class/definition.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/accessing/nextLink.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/accessing/nextLink_.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/accessing/previousLink.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/accessing/previousLink_.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/accessing/value.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/accessing/value_.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/converting/asDoubleLink.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/initialize/clearLinks.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/testing/hasPredecessor.st
A Collections-DoubleLinkedList.package/DoubleLink.class/instance/testing/hasSuccessor.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/README.md
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/definition.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/accessing/first.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/accessing/firstLink.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/accessing/last.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/accessing/lastLink.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/adding/addAll_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/adding/addFirst_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/adding/addLast_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/adding/add_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/adding/add_afterLink_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/adding/add_beforeLink_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/converting/asArray.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/collect_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/do_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/linksDo_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/reject_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/reverseDo_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/reverseLinksDo_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/enumerating/select_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/private/emptyCheck.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/removing/removeAll.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/removing/removeFirst.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/removing/removeLast.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/removing/removeLink_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/testing/includes_.st
A Collections-DoubleLinkedList.package/DoubleLinkedList.class/instance/testing/isEmpty.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/README.md
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/definition.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testAddAfterLink.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testAddBeforeLink.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testAddFirst.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testAddLast.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testCollect.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testDo.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testEmpty.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testFirstAndLastLink.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testIncludes.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testLinksDo.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testOne.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testOneRemoveFirst.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testOneRemoveLast.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testReject.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testReverseDo.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testReverseLinksDo.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testSelect.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testThree.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testThreeRemoveFirst.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testThreeRemoveLast.st
A Collections-DoubleLinkedListTests.package/DoubleLinkedListTests.class/instance/testing/testThreeRemoveLink.st
M Refactoring-Core.package/RBAddParameterRefactoring.class/README.md
M Refactoring-Core.package/RBCreateCascadeRefactoring.class/README.md
M Refactoring-Core.package/RBDeprecateMethodRefactoring.class/README.md
M Refactoring-Core.package/RBExtractMethodRefactoring.class/README.md
M Refactoring-Core.package/RBExtractMethodToComponentRefactoring.class/README.md
M Refactoring-Core.package/RBExtractToTemporaryRefactoring.class/README.md
M Refactoring-Core.package/RBInlineAllSendersRefactoring.class/README.md
M Refactoring-Core.package/RBInlineMethodFromComponentRefactoring.class/README.md
M Refactoring-Core.package/RBInlineMethodRefactoring.class/README.md
M Refactoring-Core.package/RBInlineTemporaryRefactoring.class/README.md
M Refactoring-Core.package/RBPullUpMethodRefactoring.class/README.md
M Refactoring-Core.package/RBPushDownMethodRefactoring.class/README.md
M Refactoring-Core.package/RBRealizeClassRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveClassRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveMethodRefactoring.class/README.md
M Refactoring-Core.package/RBRemoveParameterRefactoring.class/README.md
M Refactoring-Core.package/RBRenameClassRefactoring.class/README.md
M Refactoring-Core.package/RBRenameMethodRefactoring.class/README.md
M Refactoring-Core.package/RBRenameTemporaryRefactoring.class/README.md
M Refactoring-Core.package/RBSplitCascadeRefactoring.class/README.md
M Refactoring-Core.package/RBSplitClassRefactoring.class/README.md
M Refactoring-Core.package/RBSwapMethodRefactoring.class/README.md
M Refactoring-Core.package/RBTemporaryToInstanceVariableRefactoring.class/README.md
A Refactoring-Help.package/RBASTClassesHelp.class/README.md
A Refactoring-Help.package/RBASTClassesHelp.class/class/building/rootHelpClass.st
A Refactoring-Help.package/RBASTClassesHelp.class/definition.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/README.md
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/generateAccessorRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/generateSubclassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/generateSuperclassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/insertSubclassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/insertSuperclassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/realizeClassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/removeClassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/renameClassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/class/pages/splitClassRefactoring.st
A Refactoring-Help.package/RBBrowserClassRefactoringHelp.class/definition.st
A Refactoring-Help.package/RBBrowserEnvironmentsClassesHelp.class/README.md
A Refactoring-Help.package/RBBrowserEnvironmentsClassesHelp.class/class/building/rootHelpClass.st
A Refactoring-Help.package/RBBrowserEnvironmentsClassesHelp.class/definition.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/README.md
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/addParameterRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/deprecateMethodRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/inlineParameterRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/inlineTargeSendsRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/moveMethodRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/moveToClassRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/pushDownpMethodRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/pushUpMethodRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/removeMethodRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/removeParameterRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/class/pages/renameMethodRefactoring.st
A Refactoring-Help.package/RBBrowserMethodRefactoringHelp.class/definition.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/README.md
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/createCascadeRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/extractMethodRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/extractMethodToComponentRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/extractToTemporaryRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/inlineMethodFromComponentRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/inlineMethodRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/inlineTemporaryRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/moveTemporaryToInstvarRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/moveVariableDefinitionRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/renameTemporaryRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/class/pages/splitCascadeRefactoring.st
A Refactoring-Help.package/RBBrowserSourceRefactoringHelp.class/definition.st
A Refactoring-Help.package/RBBrowserSupportHelp.class/README.md
A Refactoring-Help.package/RBBrowserSupportHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBBrowserSupportHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBBrowserSupportHelp.class/class/pages/overview.st
A Refactoring-Help.package/RBBrowserSupportHelp.class/definition.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/README.md
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/abstractVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/accessorVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/addVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/moveToVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/pullUpVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/pushDownVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/removeVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/class/pages/renameVariableRefactoring.st
A Refactoring-Help.package/RBBrowserVariableRefactoringHelp.class/definition.st
A Refactoring-Help.package/RBClassesHelp.class/README.md
A Refactoring-Help.package/RBClassesHelp.class/class/building/asHelpTopic.st
A Refactoring-Help.package/RBClassesHelp.class/class/building/buildClassHierarchyHelpFrom_.st
A Refactoring-Help.package/RBClassesHelp.class/class/building/rootHelpClass.st
A Refactoring-Help.package/RBClassesHelp.class/definition.st
A Refactoring-Help.package/RBCoreClassesHelp.class/README.md
A Refactoring-Help.package/RBCoreClassesHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBCoreClassesHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBCoreClassesHelp.class/definition.st
A Refactoring-Help.package/RBRefactoringClassesHelp.class/README.md
A Refactoring-Help.package/RBRefactoringClassesHelp.class/class/building/rootHelpClass.st
A Refactoring-Help.package/RBRefactoringClassesHelp.class/definition.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/README.md
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/astContent.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/astVisiting.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/browserEnvironments.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/overview.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/overviewParser.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/patternParser.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/class/pages/patternParserExamples.st
A Refactoring-Help.package/RBRefactoringCoreHelp.class/definition.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/README.md
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/pages/combineOperationsExample.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/pages/firstExample.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/pages/overview.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/pages/refactoringOptions.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/class/pages/restrictedEnvironmentExample.st
A Refactoring-Help.package/RBRefactoringExamplesHelp.class/definition.st
A Refactoring-Help.package/RefactoringHelp.class/README.md
A Refactoring-Help.package/RefactoringHelp.class/class/accessing/bookDescription.st
A Refactoring-Help.package/RefactoringHelp.class/class/accessing/bookName.st
A Refactoring-Help.package/RefactoringHelp.class/class/accessing/pages.st
A Refactoring-Help.package/RefactoringHelp.class/class/pages/about.st
A Refactoring-Help.package/RefactoringHelp.class/class/pages/coreComponents.st
A Refactoring-Help.package/RefactoringHelp.class/class/pages/overview.st
A Refactoring-Help.package/RefactoringHelp.class/definition.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60191.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60192.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60191.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60192.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R System-Caching.package/DoubleLink.class/README.md
R System-Caching.package/DoubleLink.class/class/instance creation/value_.st
R System-Caching.package/DoubleLink.class/definition.st
R System-Caching.package/DoubleLink.class/instance/accessing/nextLink.st
R System-Caching.package/DoubleLink.class/instance/accessing/nextLink_.st
R System-Caching.package/DoubleLink.class/instance/accessing/previousLink.st
R System-Caching.package/DoubleLink.class/instance/accessing/previousLink_.st
R System-Caching.package/DoubleLink.class/instance/accessing/value.st
R System-Caching.package/DoubleLink.class/instance/accessing/value_.st
R System-Caching.package/DoubleLink.class/instance/converting/asDoubleLink.st
R System-Caching.package/DoubleLink.class/instance/initialize/clearLinks.st
R System-Caching.package/DoubleLink.class/instance/testing/hasPredecessor.st
R System-Caching.package/DoubleLink.class/instance/testing/hasSuccessor.st
R System-Caching.package/DoubleLinkedList.class/README.md
R System-Caching.package/DoubleLinkedList.class/definition.st
R System-Caching.package/DoubleLinkedList.class/instance/accessing/first.st
R System-Caching.package/DoubleLinkedList.class/instance/accessing/firstLink.st
R System-Caching.package/DoubleLinkedList.class/instance/accessing/last.st
R System-Caching.package/DoubleLinkedList.class/instance/accessing/lastLink.st
R System-Caching.package/DoubleLinkedList.class/instance/adding/addAll_.st
R System-Caching.package/DoubleLinkedList.class/instance/adding/addFirst_.st
R System-Caching.package/DoubleLinkedList.class/instance/adding/addLast_.st
R System-Caching.package/DoubleLinkedList.class/instance/adding/add_.st
R System-Caching.package/DoubleLinkedList.class/instance/adding/add_afterLink_.st
R System-Caching.package/DoubleLinkedList.class/instance/adding/add_beforeLink_.st
R System-Caching.package/DoubleLinkedList.class/instance/converting/asArray.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/collect_.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/do_.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/linksDo_.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/reject_.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/reverseDo_.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/reverseLinksDo_.st
R System-Caching.package/DoubleLinkedList.class/instance/enumerating/select_.st
R System-Caching.package/DoubleLinkedList.class/instance/private/emptyCheck.st
R System-Caching.package/DoubleLinkedList.class/instance/removing/removeAll.st
R System-Caching.package/DoubleLinkedList.class/instance/removing/removeFirst.st
R System-Caching.package/DoubleLinkedList.class/instance/removing/removeLast.st
R System-Caching.package/DoubleLinkedList.class/instance/removing/removeLink_.st
R System-Caching.package/DoubleLinkedList.class/instance/testing/includes_.st
R System-Caching.package/DoubleLinkedList.class/instance/testing/isEmpty.st
R System-CachingTests.package/DoubleLinkedListTests.class/README.md
R System-CachingTests.package/DoubleLinkedListTests.class/definition.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testAddAfterLink.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testAddBeforeLink.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testAddFirst.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testAddLast.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testCollect.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testDo.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testEmpty.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testFirstAndLastLink.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testIncludes.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testLinksDo.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testOne.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testOneRemoveFirst.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testOneRemoveLast.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testReject.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testReverseDo.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testReverseLinksDo.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testSelect.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testThree.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testThreeRemoveFirst.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testThreeRemoveLast.st
R System-CachingTests.package/DoubleLinkedListTests.class/instance/testing/testThreeRemoveLink.st
Log Message:
-----------
60192
18936 RBParser allows pragmas after method code
https://pharo.fogbugz.com/f/cases/18936
18829 Add a RefactoringFramework System HelpTopic
https://pharo.fogbugz.com/f/cases/18829
18955 DoubleLinkedList and its test should be in its own package
https://pharo.fogbugz.com/f/cases/18955
http://files.pharo.org/image/60/60192.zip
Aug. 24, 2016
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60192
Home: https://github.com/pharo-project/pharo-core
Aug. 24, 2016
Re: [Pharo-dev] About better communication in the community
by stepharo
Hi Hernan
First thanks for your email because we may disagree but we often agree.
:) so this is an email for me.
> Hi Stef,
>
> Good communication implies being clear when writing about sensitive
> topics, especially when communicating through virtual channels. I am
> not in Europe, so I cannot discuss these things with you face to face.
This is what we want to change with montly videos meeting.
> Therefore is not clear to me (and others) what are your policies in
> many subjects. Lately I also delayed the release of packages because
> my lack of motivation around this community, specially when
> discussions exists around three or fourth topics for months.
Like what?
Let us know because we do not
> Another "motivational" case for me. I stopped to report bugs in fogbuz
> because I felt there was too much "Won't fix" for me (specifically by
> a person but I won't go there...) even in cases where it was ilogical.
> Then I felt tired of reading "It's like that. Invalid".
This is a pity.
I know the feeling because some of mine are close too. You are not the
only victim of the "Issue closing syndrom" ;).
And I would like the syndrome to be more human friendly. Thanks for
raising this point.
Now two points
- You should always send a mail to the mailing-list and that we
discuss your points.
- Now what will happen if we all open bugs and none of us works on
the open bugs.
So what is the solution for you. I mean it concretely. How to deal with
dying
Looking at bugs is really difficult. There are not enough people looking
and fixing bugs.
> About features.
>
> What's the policy about voting for default features in next Pharo
> images? Let's suppose I am a VM/core Pharo maintainer and I want to
> include MySuperPackage into a Pharo release, which nobody needs (and I
> don't care), but it is useful to me.... there will ever be voting
> there? (note it doesn't makes sense if you are a group of 50 always
> supporting your work)
It does not really work because engineers are paid for certain task.
> Images are becoming huge (at least for my workflows). There will be
> (more) packages included by default (for promotion?) ?
Thanks to raise this point because I mentioned it also to the board. So
I like when I'm not alone.
Now we should not see look only at the size. Doing nothing is size zero :)
The point is what are the functionalities delivered.
Three points:
- what are the key things we want?
keybinding, settings, cool inspector cool....
- how many duplicated functionality can we remove:
for example I want to merge MCDefinitions with Ring with
RBDefinition
we removed pseudo*
but this is a lot of work
The goal is to throw many system when bloc and brick are ready
- what is the list of things that you would remove?
- with the bootstrap and all the packages of the image managed with
Cargo plus the git management
we believe that we will be able to manage a set of images with
minimal images.
- this is several years that we are working on this goal.
Believe me this is the vision document not for the sake of it.
> How do you plan to manage if some people want the Tests be removed
> from the official Image? (Personally I never run them)
- then you use a jenkins job to produce your image where you unload
the tests.
> Another example, what happens if another research group came with a
> better alternative to Calypso, Brick, Telescope, Bloc. Would you
> integrate first your tool to mark territory?
No this is not a question of territory. Doru and GT does not do
that in that spirit.
RMOD too. We do something when we think that this is better.
For example Epicea is three years of work of Martin, Fuel was so
nice that we could not lose it.
You see Ghost got changed by denis, Seamless got rewritten from
scratch.
> Who decides? For example (IIRC) TxText and Twisty.
Igor looked at Twisty seriously and I do not think that it could
handle large cobol files.
(you see funnily denis is doing the same with Seamless - He rewrote
it from scratch while
nick worked on it for several years).
Igor wanted to have a stream-based API that could work on modern
command-oriented videos card framework.
My team (on our own money if you understand what it means)
paid Igor to build TxText (and I can tell you that I would have
prefered him to do something else).
> The same applies if anyone came with another rewrite of classic
> Smalltalk Workspace, Debugger and Inspector tools, what would you do
> with GT? GT stays because it came before and others would be optional?
No this is not like that.
If you are better or answer better needs.
> There will be anything like PEPs?
I would love but will people have the energy to implement them?
I would definitively encourage you as a community to raise points
on what you need.
> If someone can answer me I think that would be an example of good
> communication.
Hernan I always answered your emails. I always consider your work
(and you know it for other reasons and by my facts) after I'm not always
in agreement as I'm not always in agreement with other board members and
this is how live happens.
What is clear is that the most important aspects is to continue to
communicate. This is why the board is launching
this initiative and I would love to see it taken by people even for
their projects.
>
> Hernán
>
>
> 2016-08-24 1:51 GMT-03:00 stepharo <stepharo(a)free.fr
> <mailto:stepharo@free.fr>>:
>
> Hi guys
>
> the board got a good discussion at ESUG about how to improve and a
> lot of the discussion turned around improving communication. We
> got some ideas that we will propose soon but I would like to get
> *your* ideas.
>
> If you have idea about improving communication around pharo please
> tell us.
>
>
> Stef
>
>
>
Aug. 24, 2016