- Pharo-dev - lists.pharo.org

TEXT drag and drop
by lb May 21, 2016

May 21, 2016

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: ''

5 7

how to swallow a syntax error?
by Tudor Girba May 21, 2016

May 21, 2016

Hi, I am having trouble making the compiler not be interactive when it encounters a syntax error. To reproduce the problem I attach here an .st file that has a funny character in the method name. If I file this in, like: âAAA.stâ asFileReference fileIn. I get a Syntax Error dialog. I would like to avoid that. After diving in, I noticed that I can tell the requestor of the CodeImporter to not be interactive, but that does not seem to have an effect: 'AAA.st' asFileReference readStreamDo: [ :s | importer := CodeImporter fileStream: s. importer requestor interactive: false. importer evaluateDeclarations ] I also tried to play on the end of the SyntaxErrorDebugger, and replace it with something that logs the exception, but I was not successful because that one is expected to return a string that can be compiled. Can anyone point me in the right direction? Cheers, Doru -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

2 2

Should we updated UpdatedPharoByExample for Pharo 5?
by Cyril Ferlicot D. May 21, 2016

May 21, 2016

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

3 4

Minutes of the Meeting to Discuss Moving Cog to Github
by Eliot Miranda May 21, 2016

May 21, 2016

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

4 4

Re: [Pharo-dev] TEXT drag and drop (Torsten Bergmann)
by lb May 21, 2016

May 21, 2016

Thank you Torsten and Esteban I desire to be a contributor of Pharo. Cheers! Liang Bing

2 1

GT inspector: how to get side by side panes
by stepharo May 21, 2016

May 21, 2016

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

3 3

[pharo-project/pharo-core]
by GitHub May 21, 2016

May 21, 2016

Branch: refs/tags/60027 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] d0636f: 60027
by GitHub May 21, 2016

May 21, 2016

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: d0636f96268209a1251cd9dd3227c94455395619 https://github.com/pharo-project/pharo-core/commit/d0636f96268209a1251cd9dd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-21 (Sat, 21 May 2016) Changed paths: M AST-Core.package/RBBlockNode.class/instance/accessing/statementComments.st A BlueInk-Core.package/BIConfigurableFormatter.class/instance/private-formatting/formatBlockCommentFor_.st M BlueInk-Core.package/BIConfigurableFormatter.class/instance/private-formatting/formatBlock_.st A BlueInk-Core.package/BIConfigurableFormatter.class/instance/private/isNonEmptySingleLineBlock_.st M Refactoring-Core.package/RBAbstractClass.class/README.md M Refactoring-Core.package/RBClass.class/README.md M Refactoring-Core.package/RBMetaclass.class/README.md M Refactoring-Core.package/RBMethod.class/README.md M Refactoring-Core.package/RBNamespace.class/README.md R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60026.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60027.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60026.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60027.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60027 18253 formatter misplaces some block comments https://pharo.fogbugz.com/f/cases/18253 18267 Add Class comments to Refactoring-Core-Model classes https://pharo.fogbugz.com/f/cases/18267 18284 SmallFloat64 identityHash is answering bad value https://pharo.fogbugz.com/f/cases/18284 http://files.pharo.org/image/60/60027.zip

1 0

Re: [Pharo-dev] [Vm-dev] Minutes of the Meeting to Discuss Moving Cog to Github
by Eliot Miranda May 21, 2016

May 21, 2016

Hi Juan, On Fri, May 20, 2016 at 12:57 PM, Juan Vuletich <JuanVuletich(a)zoho.com> wrote: > Hi Folks, > > This is just great! > > I assume builds will include: > - V3, Cog, 32bitBinaries > - Spur32, Cog, 32bitBinaries > - Spur64, Cog, 64bitBinaries > Yes. > > Would it also be possible to include: > - V3, Stack, 32bitBinaries > - Spur32, Stack, 32bitBinaries > - Spur64, Stack, 64bitBinaries > ? > I think so. Tim F tells me that Github support for open source projects is free, including disk space, so there's nothing to stop us including a comprehensive suite of VMs. > I think that having the non-Cog builds always green could benefit those > platforms where code generation is not possible, and might ease porting to > new platforms. Especially for Spur64. > Indeed, I hope that with the new repository it will be much easier for the people who got the VM working on iPad to integrate their changes. It should also be possible to have Linux ARM v6 (Pi) and Linux ARM v7 (Android) VMs. > > Thanks you all! > Juan Vuletich > > > On 5/20/2016 2:28 PM, Eliot Miranda wrote: > > > > 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

2 1

Pharo IDE in Amber?
by Siemen Baader May 21, 2016

May 21, 2016

Hi All, I am cross posting this to the Amber and Pharo-dev lists as the both seem equally relevant, I hope that's ok. Iâd like to discuss what the options would be to offer Pharoâs great IDE support in Amber. Helios and the classic IDE are great and a huge leap forward for in-browser live development, but Pharo is evolving rapidly. Also, having a full window system allows other workflows like inspecting classes and mocking something up in the Playground at the same time. Is there a way to make Amber and the Pharo developer tools be source code compatible, so that we could simply have the IDE open in a pop-up (like Helos), but have the Pharo desktop there? It would be very nice if this could be a once-and-for-all integration so that Amber would just use the current Pharoâs Desktop. I realize that there must be some challenges in that Amber does not have the same data types available (ie no Integer class, only Number, fewer collection types), but perhaps they can be introduced in Amber. There must be issues with concurrency models & callbacks that work differently in Pharo and the browser as well. If this can be overcome, I think the options would be to either: a) implement a Morphic raster rendering backend based on HTML5 Canvas, or: 2) create DOM & CSS based Morphic widgets, like the Lively Kernel does. What do you think? best, Siemen

2 1