April 2015 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Recommended image resolution for Pillar books?

by Dmitri Zagidulin

How would one do that? Does the width attribute take HTML style parameters (px, %)? On Tuesday, April 21, 2015, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Dmitri Zagidulin <dmitri(a)zagidulin.net <javascript:;>> writes: > > > 2. Does it matter (is it advantageous) whether one puts the width= > > attribute on the figure declarations? > > > I would use the width attribute to size the image with respect to his > surrounding text (e.g., half of the line width). > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

April 21, 2015

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

by Stephan Eggermont

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. Stephan

April 21, 2015

Re: [Pharo-dev] GNU/Linux Old libC CI Job

by Sean P. DeNigris

stepharo wrote > We should probably put a link on the web site. They are there :) http://pharo.org/download#custom ----- Cheers, Sean -- View this message in context: http://forum.world.st/GNU-Linux-Old-libC-CI-Job-tp4820686p4820804.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 21, 2015

Re: [Pharo-dev] TDD and BDD

by Sean P. DeNigris

Miguel Moquillon wrote > BDD and TDD stands for different purposes with different actors... While that's unfortunately often true in practice, there is no difference philosophically. [T|B]DD "done right" always focuses on the user. But because of the word "test" in TDD, many tests (including many in our image) became incomprehensible from a "how do I use this library" POV, tested internal implementation details, etc. So BDD was invented to make the focus on behaviors explicit and to guide us all toward best practice. It also quite nicely unified acceptance testing and unit testing. The "In order to..." that you're describing is the outer, high-level acceptance test that in Ruby for example might be written with Cucumber. But once one has a failing acceptance test, the next step in BDD is to drop down into e.g. RSpec and write something a lot closer to a unit test, often mocking out collaborators to drive creation of an API. In summary, the intent of BDD is to be "TDD Done Right". There is no inherent conflict, and no specific tools are technically required. Although, since as McLuhan suggested, we become our tools, so obviously the proper tools may be decisive, especially when first learning. ----- Cheers, Sean -- View this message in context: http://forum.world.st/TDD-and-BDD-tp4820612p4820803.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 21, 2015

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

by Christophe Demarey

Le 20 avr. 2015 Ã 20: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! > great work Sean! It was really something missing. Thanks

April 21, 2015