May 2016 - Pharo-dev - lists.pharo.org

the fastest way to load external code

by Tudor Girba

Hi, I am looking for ways to make loading of code from an st file faster. To this end, I would like to find in-image mechanisms that are not mandatory for obtaining a functional image. For example, one place I look at is SystemAnnouncer uniqueInstance, and I know that I should have no Nautilus open and that I can disable Renraku and GTExample: ReRuleManager uniqueInstance unsubscribe. GTExampleOrganizer instance stopSystemAnnouncements. What else do you see around? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Don't give to get. Just give."

May 21, 2016

Re: [Pharo-dev] [Vm-dev] Aw: Minutes of the Meeting to Discuss Moving Cog to Github

by Eliot Miranda

On Fri, May 20, 2016 at 6:22 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Cool to see that happen now. Future now looks even brighter. > Big, big thanks to anyone who was/is involved!!! > > Some questions: > > 1. Whoever has access for Squeak: is it planned to update > http://www.squeakvm.org with that info? > Thanks for the reminder. We will make that happen. > 2. Will http://www.mirandabanda.org/files/Cog/VM/ stay and get updated > with binaries or will > these be hosted on GitHub in the future as well? > I expect everything will migrate to Github. But hopefully links can be designed so that links from mirandabanda.org point to the relevant artefacts on github.com/OpenSmalltalk/vm. > 3. Is there any effect on http://files.pharo.org/vm/ ? > > Bye > T. > > *Gesendet:* Freitag, 20. Mai 2016 um 19:28 Uhr > *Von:* "Eliot Miranda" <eliot.miranda(a)gmail.com> > *An:* "Squeak Virtual Machine Development Discussion" < > vm-dev(a)lists.squeakfoundation.org> > *Cc:* "newspeaklanguage(a)googlegroups.com" < > newspeaklanguage(a)googlegroups.com>, "Discussion of Cuis Smalltalk" < > cuis-dev(a)cuis-smalltalk.org>, "Discusses Development of Pharo" < > pharo-dev(a)lists.pharo.org>, "The general-purpose Squeak developers list" < > squeak-dev(a)lists.squeakfoundation.org> > *Betreff:* [Pharo-dev] Minutes of the Meeting to Discuss Moving Cog to > Github > Hi All, > > here are the minutes of, and action items arising from, the meeting on > Wednesday 18th of May to discuss moving the Cog svn repository to Github. > Please read if you're interested and discuss on vm-dev. The major decision > for the community to participate in is when to make the change, which we > hope will happen in the next few weeks. Thanks to all who attended the > meeting and to all who have helped in making this a reality. This is > exciting! > > > VM Move to Github Meeting Notes > > The name of the organisation and repository was agreed to be, and has been > created as > > Organisation name: OpenSmalltalk > > Repository name: vm > > URL: github.com/OpenSmalltalk/vm > > > Administration duties: > > - > > Tim Felgentreff, David Lewis, Esteban Lorenzano, Eliot Miranda > > > > We decided to have everyone who currently has access to SVN also get write > access to the new repository. > > > There will be a master branch that is stable and from which releases are > made using tags. Only administrators integrate into that branch. Ongoing > development will be on a âdevâ branch. This should also be kept stable for > collaboration purposes, but breakage can happen occasionally. Contributors > working on larger changes will do so on separate branches to avoid > conflicts/breaking other peopleâs code. > > > Every commit will be tested by Travis (and Appveyor for Windows). Builds > and tests will be run for Windows, Linux, and OS X, both on 32-bit, 64-bit, > and ARM (as applicable). The master will only ever be merged with green > commits. The dev branch should be green, and if something breaks, but the > committer has no access or no time to fix it, we agreed that any > administrator may roll back the breaking change using git revert. This way, > the breaking change is preserved in the history, but the current HEAD is > green. We will also disable âforce-pushingâ to the repository to ensure > that no commit history can be tampered with. > > > In case of any disagreements about reverting other peopleâs code, we > declared Eliot (*) to be the arbiter. > > > Release tags on the master will trigger Travis to build release artifacts, > including debian packages. > > > To have incremental monotonic, human-readable version identifiers, we > decided to use timestamps in the form YYYYMMDDHHmm in UTC. In order to > ensure these timestamps are included in the sources, we will have a commit > script in the repository that any contributor must use to update the dev > and master branches (**). The checkout command for any version then becomes > âgit checkout branch@{timestamp}â. Both the built VMs via a -version > flag, and sources via a header file, will be marked with these timestamps. > > > It was decided to leave the build system as-is using GNU Makefiles where > available with a commitment to move to GNU Makefiles on Linux. We will use > CMake to produce per-platform config files that identify platform > facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3)). > > We discussed ethics, which derive from the âif you break it, you fix itâ > philosophy and distilled it into the âadministrators may revertâ policy > above. We donât want to prevent breakages, nor make people afraid of > breaking things. We merely want to prevent other people being affected by > breakages, especially those that may be operating under production or time > constraints. > > > We will integrate the Github commit notifications with a Codespeed > instance that will test commits for performance regressions. > > > Action Items > > > - > > Write the commit script > - > > Set a date for the move (sooner rather than later) > - > > Move the repository > - > > Enable automatic builds for all the platforms > - > > Write GNU makefiles for unix/linux > - Make WebHooks for Commit Notifications available to anyone who wants > them. > - Write CMake code to generate per-platform headers (***) > > > > _,,,^..^,,,_ > best, Eliot > > (*) under protest > (**) use whatever versioning you want on your own versions, but the > versions in OpenSmalltalk/vm will use this convention exclusively > (***) which will /not/ be called "config.h", but e.g. "ostvmConfig.h", so > as to avoid conflicts with other packages using autoconf and CMake > > -- _,,,^..^,,,_ best, Eliot

May 21, 2016

Re: [Pharo-dev] Should we updated UpdatedPharoByExample for Pharo 5?

by Cyril Ferlicot D.

Le 21/05/2016 15:56, stepharo a Ã©crit : > Hi cyril > > > I think that we should find the right balance between details that are > specific to a version and stable parts. > > Now I target Pharo 50. I think that the focus of Pharo 60 should be on > external (new tools) but on stabilisation, speed up and > > cleanup (and internal things like bootstrap). > > Stef > Ok, so if nobody disagree I think we should tag the current version as Pharo 4. Mark the current Jenkins build as "Always keep artefact" and publish a link on the book's page. I can do the two first steps but not the last. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop

by Thierry Goubier

Le 21/05/2016 15:58, stepharo a Ã©crit : > How can I see the effects of your changes? Install both packages that are in that smalltalkhub archive, and try dragging a text selection. At least, that process works for PluggableTextMorph. Nice demonstration of both the drag and drop api and the text api, because it's even nicely undoable in the editor :) Thierry > > Stef > > > Le 18/5/16 Ã 19:09, lb a Ã©crit : >> Hi, >> I have made a little tool for draging and dropping text selection. >> like windows Word. >> It can work in Pharo 40 50 and 60. >> >> Have a fun! >> >> LiangBing >> >> MCHttpRepository >> location: >> 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' >> user: '' >> password: '' >> >> >> >

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop

by stepharo

How can I see the effects of your changes? Stef Le 18/5/16 Ã 19:09, lb a Ã©crit : > Hi, > I have made a little tool for draging and dropping text selection. > like windows Word. > It can work in Pharo 40 50 and 60. > > Have a fun! > > LiangBing > > MCHttpRepository > location: > 'http://www.smalltalkhub.com/mc/liangbing/Text-DragDrop/main' > user: '' > password: '' > > >

May 21, 2016

Re: [Pharo-dev] Should we updated UpdatedPharoByExample for Pharo 5?

by stepharo

Hi cyril I think that we should find the right balance between details that are specific to a version and stable parts. Now I target Pharo 50. I think that the focus of Pharo 60 should be on external (new tools) but on stabilisation, speed up and cleanup (and internal things like bootstrap). Stef Le 21/5/16 Ã 15:00, Cyril Ferlicot D. a Ã©crit : > Currently all issues are opened to update PBE for Pharo4. Since Pharo5 > is out should we give up on Pharo4 version and focus on Pharo5? > > Since we don't have enough man power to do both I think we should just > tag the current version with a Pharo4 tag even if everything is not up > to date and begin to adapt it for Pharo5. >

May 21, 2016

Re: [Pharo-dev] Should we updated UpdatedPharoByExample for Pharo 5?

by Dimitris Chloupis

UPBE always targets the current stable version of Pharo. In this case is Pharo 5 , a year ago was Pharo 4 and in a year Pharo 6. The tag is an idea I also promoted. We do have more than enough man power unfortunately a tiny fraction of it contributes to UPBE. I am not complaining, its free software people should choose what they like doing . On Sat, May 21, 2016 at 4:02 PM Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Currently all issues are opened to update PBE for Pharo4. Since Pharo5 > is out should we give up on Pharo4 version and focus on Pharo5? > > Since we don't have enough man power to do both I think we should just > tag the current version with a Pharo4 tag even if everything is not up > to date and begin to adapt it for Pharo5. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >

May 21, 2016

Should we updated UpdatedPharoByExample for Pharo 5?

by Cyril Ferlicot D.

Currently all issues are opened to update PBE for Pharo4. Since Pharo5 is out should we give up on Pharo4 version and focus on Pharo5? Since we don't have enough man power to do both I think we should just tag the current version with a Pharo4 tag even if everything is not up to date and begin to adapt it for Pharo5. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

May 21, 2016

Re: [Pharo-dev] TEXT drag and drop (Torsten Bergmann)

by stepharo

super and we are honored. Can you sign the license agreement and send it to me? http://pharo.org/contribute Le 19/5/16 Ã 18:36, lb a Ã©crit : > Thank you Torsten and Esteban > I desire to be a contributor of Pharo. > > Cheers! > Liang Bing > > >

May 21, 2016

Re: [Pharo-dev] GT inspector: how to get side by side panes

by stepharo

Ok click several times on self stef Le 21/5/16 Ã 09:16, Tudor Girba a Ã©crit : > Hi, > > This is not really possible in the current implementation. > > Cheers, > Doru > > >> On May 21, 2016, at 9:03 AM, stepharo <stepharo(a)free.fr> wrote: >> >> I would like to see different views of a compiled method (source, bytecode) side by side >> >> >> Is there a way to see a new pane (describing a different aspect) on the right without been force to click on >> >> an element of the objects? >> >> I tried option alt control + click >> >> >> Stef >> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "To utilize feedback, you first have to acquire it." > > >

May 21, 2016