- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Phaor 50: updating Metacello

by stepharo

> Stef, > > While in development you should be doing builds with the most recent > version on the github master branch ... that way if you hit problems > and Christophe or I have bugfixes along the way, yes > those fixes will be folded into the latest build ... I will add > Pharo5.0 to my travis testing lineup shortly ...

April 21, 2015

Re: [Pharo-dev] New Download instructions (esp. for GNU/Linux)

by stepharo

Superb! Thanks for making Pharo experience much better. Stef Le 20/4/15 21:23, Sean P. DeNigris a Ã©crit : > We revamped the download instructions to incorporate the new VM builds and > platform all-in-ones. The biggest improvement was that GNU/Linux now has its > own instruction page laying out the various options and gotchas. Of course > we should continue to improve, but IMHO we have addressed the most > persistent gotchas. > > Check out the pages: http://pharo.org/download and > http://pharo.org/gnu-linux-installation (which is linked from the first) > > Next up: we'd like to use the OpenBuildService to build from sources for all > supported GNU/Linux configurations. Help is welcome! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/New-Download-instructions-esp-for-GNU-Linux-tp4820692… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Stephan Eggermont

On 21/04/15 14:53, Esteban Lorenzano wrote: > >> On 21 Apr 2015, at 14:37, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 21/04/15 13:14, Esteban Lorenzano wrote: >> >>> nope, solution is to explicit version to load :) >> >> Explicit symbolic version, that is. >> Never a fixed number, as that can't be patched. >> That breaks the update process just as well. > > noâ¦ explicit fixed number. I need version 1.0.42, not #stable or #myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42 > And of course can be patchedâ¦. with version 1.0.43. > Thatâs the only way to be able to make the update process work. The explicit version number is something you record while loading and put in a snapshot class/log. Please think through how this is supposed to work, for all stakeholders involved. Stephan

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by stepharo

@esteban Pavel is not stupid. So we could ask him what are his scenarios. @Pavel So pavel can you explain what and why you need? And yes we will have to have another level of tooling because now it can be really difficult @esteban we should add the repositories to the projects because we should be able to publish in this repositories. Else it will be again the time of the guy fixing a problem that will be consumed. Or we can also simply say to people that we do not care of their time, but I would prefer that we pay attention. In that case this is simple for me I will not fix or even look at code that is not in the main system and with this approach we will all have lost something. Stef

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by stepharo

Le 21/4/15 12:49, Esteban Lorenzano a Ã©crit : > >> On 21 Apr 2015, at 11:42, Ben Coman <btc(a)openinworld.com >> <mailto:btc@openinworld.com>> wrote: >> >> btw, how do you merge Configurations? For example, if I fix >> something "X" in my image and continue to work in it a month while >> the Image Configurations move forward, how do avoid losing that fix >> when I update to the latest Configuration ? > > you *do not* merge configurations. > if you fix something in a âconfiguredâ project, you submit your > change to proper repository (not as a SLICE, as regular packages), > which in time will be included (or not, if âproject ownerâ rejects it) > in a new configutation that will be included in Pharo. > > thatâs how any complex project worksâ¦ and thatâs how we should work > too. SLICES are just a patch that exists because our system still not > modular enough. Well in reality you will still use slice because reality is more complex than our dreams. But you are right at the conceptual point of view :) > >> >> Actually I guess it would be useful if a Configuration could be >> merged with the same GUI that merges a Slice. > > wellâ¦ monkey and integrator app (integrators use it) does the proper > loading. > But I insist: configurations are not merged: versions are loaded, > instead. > > cheers. > Esteban > >> >> cheers -ben >> >> On Tue, Apr 21, 2015 at 2:47 PM, Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> > On 21 Apr 2015, at 08:06, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> > >> > It means that we should also add the repositories of these >> projects so that MC can merge no? >> well, but you should not merge this projects :) >> >> > >> > Le 20/4/15 22:19, Esteban Lorenzano a Ã©crit : >> >> they are handled separately, through configurations. >> >> >> >> cheers, >> >> Esteban >> >> >> >>> On 20 Apr 2015, at 21:02, Pavel Krivanek >> <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >>> >> >>> Hi, >> >>> >> >>> these packages do not have a version in the Pharo50 repository: >> >>> >> >>> Athens-Balloon >> >>> Athens-Cairo >> >>> Athens-CairoPools >> >>> Athens-Core >> >>> Athens-Examples >> >>> Athens-Morphic >> >>> Athens-Text >> >>> ConfigurationOfAthens >> >>> ConfigurationOfGlamourCore >> >>> ConfigurationOfGTInspectorCore >> >>> ConfigurationOfGToolkitCore >> >>> ConfigurationOfGTPlaygroundCore >> >>> ConfigurationOfGTSpotter >> >>> ConfigurationOfOSWindow >> >>> ConfigurationOfRubric >> >>> ConfigurationOfShoreLineReporter >> >>> ConfigurationOfTxText >> >>> ConfigurationOfVersionner >> >>> ConfigurationOfZincHTTPComponents >> >>> Glamour-Announcements >> >>> Glamour-Browsers >> >>> Glamour-Core >> >>> Glamour-Examples >> >>> Glamour-Helpers >> >>> Glamour-Morphic-Brick >> >>> Glamour-Morphic-Brick-Tests >> >>> Glamour-Morphic-Pager >> >>> Glamour-Morphic-Renderer >> >>> Glamour-Morphic-Theme >> >>> Glamour-Morphic-Widgets >> >>> Glamour-Presentations >> >>> Glamour-Rubric-Presentations >> >>> Glamour-Tests-Core >> >>> Glamour-Tests-Morphic >> >>> Glamour-Tests-Resources >> >>> Glamour-Tests-Rubric >> >>> GT-Inspector >> >>> GT-InspectorExtensions-Core >> >>> GT-Playground >> >>> GT-Spotter >> >>> GT-Spotter-EventRecorder >> >>> GT-SpotterExtensions-Core >> >>> GT-Tests-Inspector >> >>> GT-Tests-Playground >> >>> GT-Tests-Spotter >> >>> OSWindow-SDL2 >> >>> OSWindow-VM >> >>> Rubric >> >>> ShoreLine-Report-Core >> >>> ShoreLine-Report-Settings >> >>> ShoreLine-Report-UI >> >>> TxText-AthensTests >> >>> TxText-Model >> >>> TxText-Styler >> >>> TxTextTests-Model >> >>> Versionner-Core-Commands >> >>> Versionner-Core-Model >> >>> Versionner-Spec-Browser >> >>> Versionner-Tests-Core-Model >> >>> Zinc-HTTP >> >>> Zinc-Character-Encoding-Core >> >>> Zinc-Character-Encoding-Tests >> >>> Zinc-Resource-Meta-Core >> >>> Zinc-Resource-Meta-Tests >> >>> Zinc-Tests >> >>> Zinc-Zodiac >> >>> Zodiac-Core >> >>> Zodiac-Tests >> >>> >> >>> Cheers, >> >>> -- Pavel >> >>> >> >> >> >> >> > >> > >> >> >> >

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Thierry Goubier

2015-04-21 14:53 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > > On 21 Apr 2015, at 14:37, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > On 21/04/15 13:14, Esteban Lorenzano wrote: > > > >> nope, solution is to explicit version to load :) > > > > Explicit symbolic version, that is. > > Never a fixed number, as that can't be patched. > > That breaks the update process just as well. > > no... explicit fixed number. I need version 1.0.42, not #stable or > #myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42 > And of course can be patched.... with version 1.0.43. > Where are those version numbers stored? Is it possible to modify a configuration outside and break that process? That's the only way to be able to make the update process work. > No. Thierry > > Esteban > > > > > Stephan > > > > > > >

April 21, 2015

Improving the documentation model

by stephan

TL;DR: Some roadmap ideas. Looks like a lot of work. Comments and improvements welcome: We should replace the Pillar document format by a better one, suitable for WYSIWYG editing and creating long documents. --- The current documentation model for Pharo is Pillar. Pillar is the document model from the Pier CMS and provides exports to (a.o) html and LaTeX. It is a simplified form of the LaTeX document model without a WYSIWYG UI. In the research world two documentation systems dominate: LaTeX and Word. Word and its clones dominate areas where ease of use for small papers without maths are important, LaTeX the other fields. From personal experience I know that the lack of abstraction in Word and clones makes it very expensive to create large, consistently formatted documents. In addition, the typographical quality of the resulting documents is much lower than that achievable with LaTeX. On the other hand, repurposing LaTeX to generate anything other than PDF/paper documentation is difficult because of the underlying language that LaTeX is written in, and there is no easy to use WYSIWYG UI for LaTeX. It pains me to see the return of text based formatting with primitive formats like markdown. At least in LaTeX you can preserve semantics level content, in markdown we are back at html 1.0. The program I liked best for creating longer documents was Framemaker. That provided the needed abstractions in an efficient WYSIWYG UI. Framemaker was sold from 1986, so the performance of current hardware should be enough to run something similar in smalltalk. I used versions 5.5 and 6, and had to abandon it when Adobe stopped development and it was never migrated from PowerPC. Framemaker was fast enough to create books with hundreds and even thousands of pages. It had working versions of the long document features Word claimed to have. With Athens and TxText we now have low level abstractions for dealing with cursor and selection, fonts, rendering glyphs and having both on-screen and PDF output. On top of TxText we could add a model somewhat like the attached figure UML diagram of document structure A book consists of a number of named documents. This is essential for dealing with longer material, as in a wysiwyg system we want to avoid having to re-layout too much after a key is pressed. Across documents we only need to remember the starting page/section numbers. Each document consists of pages. On a page there can be fixed content and content that is dependent on the text flow. Most pages of a document have a similar layout, so each page refers to a masterpage that defines the default content. A document can have separate masterpages for first, left and right pages, and rotated or extra large ones. A masterpage can define fixed items and calculated ones (pagenumbers and current chapter). A textframedefinition describes the textframes and the textflow for each textframe. The text (and other in-line contents) of the document are stored in paragraphs, which are stored in textflows. The paragraphstyle of a paragraph knows how to layout it in a textframe, and how to deal with the end of a textframe. The paragraphstyle knows how to paginate, how to number or provide other autotext at the beginning of a paragraph and if the paragraph text should be part of a table of contents. A textframe is a (rectangular) area on a page. The characterstyle of a paragraph is responsible for the font family, size and style. The characterstyle can be overridden by a specific paragraph or by a textrange. With a model like this (and adding maths, tables, notes, figures and references) we should be able to use Pharo to create both high-quality documentation, and write research articles (and books) in-image. Stephan

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Ben Coman

On Tue, Apr 21, 2015 at 5:49 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 21 Apr 2015, at 11:42, Ben Coman <btc(a)openinworld.com> wrote: > > btw, how do you merge Configurations? For example, if I fix something "X" > in my image and continue to work in it a month while the Image > Configurations move forward, how do avoid losing that fix when I update to > the latest Configuration ? > > > you *do not* merge configurations. > I might have the wrong end of the stick, but I just want to push this idea to the extreme for a moment, since I thought merging was the very essence of collaborative development. Git seems to have become popular in part because it makes it very easy to *merge* parallel paths of development. How do you avoid feature development interfering with fast bug fixing without multiple paths of development (i.e. multiple Configurations) and hence without making it easy to merge Configurations. Suppose a developer outside the core group submits a feature/bug-fix across five packages of the project's Configuration. Should those packages just be dropped into the project's repository? How do you tag them as belonging-together, to simplify review by the project's owner - especially if some of those packages are in different repositories. I expect it would be simpler if the outside-developer dropped a Configuration for the feature/bug-fix, and the project owner could *merge* it into their image to view all changes in one step. cheers -ben > if you fix something in a âconfiguredâ project, you submit your change to > proper repository (not as a SLICE, as regular packages), which in time will > be included (or not, if âproject ownerâ rejects it) in a new configuration > that will be included in Pharo. > > thatâs how any complex project worksâ¦ and thatâs how we should work too. > SLICES are just a patch that exists because our system still not modular > enough. > > > Actually I guess it would be useful if a Configuration could be merged > with the same GUI that merges a Slice. > > > wellâ¦ monkey and integrator app (integrators use it) does the proper > loading. > But I insist: configurations are not merged: versions are loaded, instead. > > cheers. > Esteban > > >

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Norbert Hartl

> Am 21.04.2015 um 14:53 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > >> On 21 Apr 2015, at 14:37, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 21/04/15 13:14, Esteban Lorenzano wrote: >> >>> nope, solution is to explicit version to load :) >> >> Explicit symbolic version, that is. >> Never a fixed number, as that can't be patched. >> That breaks the update process just as well. > > noâ¦ explicit fixed number. I need version 1.0.42, not #stable or #myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42 > And of course can be patchedâ¦. with version 1.0.43. > Thatâs the only way to be able to make the update process work. > +1 Norbert

April 21, 2015

Re: [Pharo-dev] missing packages in the Pharo50 repository

by Esteban Lorenzano

> On 21 Apr 2015, at 14:37, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 21/04/15 13:14, Esteban Lorenzano wrote: > >> nope, solution is to explicit version to load :) > > Explicit symbolic version, that is. > Never a fixed number, as that can't be patched. > That breaks the update process just as well. noâ¦ explicit fixed number. I need version 1.0.42, not #stable or #myCoolFantasyNumberWichAfterAllIsEqualButWorstTo-1-0-42 And of course can be patchedâ¦. with version 1.0.43. Thatâs the only way to be able to make the update process work. Esteban > > Stephan > >

April 21, 2015