March 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] GitFileTree Version Numbering

by Thierry Goubier

2015-03-09 11:39 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Martin BÃ¤hr wrote > >> It takes ages to scan the version metadata contained in the git > >> repository. > > why is that? > > Also, this is a copy operation, so we already have the version number from > the mcz! Why can't we just use that? > No problem, just make a correct clone with the full history of your MC repository and you'll get the right version number :) There is technical limitations in adding that information (or using it). I did use it a long time ago at the beginning of gitfiletree, but it was prohibitively slow, even on small git repositories. I would have been pleased by a Package-Author.Commit.mcz approach however, but the numbering scheme in MC is so hopelessly broken and unreliable anyway that it's not worth the hassle. The only thing correct in MC is the UUID, but, except in very specific cases, it isn't used because it's too costly to check it. Thierry

March 9, 2015

Any framework to create a blog over seaside?

by Julien Delplanque

Hi, I wonder if there are existing projects/frameworks to create a blog in pharo? If there are I suppose they use seaside? Regards, Julien

March 9, 2015

Re: [Pharo-users] GitFileTree Version Numbering

by Sean P. DeNigris

Martin BÃ¤hr wrote >> It takes ages to scan the version metadata contained in the git >> repository. > why is that? Also, this is a copy operation, so we already have the version number from the mcz! Why can't we just use that? ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitFileTree-Version-Numbering-tp4810543p4810614.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 9, 2015

Re: [Pharo-users] Notebook/slideshow morph

by Sean P. DeNigris

Torsten Bergmann wrote > Would be a nice addition to recreate some of the presentation and > multimedia features known from Squeak now also in Pharo. Please x 100!!! I will help :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Notebook-slideshow-morph-tp4810579p4810613.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 9, 2015

Re: [Pharo-users] smaller configurations vs groups [was Re: Pillar and GT tools in Pharo4]

by Tudor Girba

Hi, On Mon, Mar 9, 2015 at 10:06 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 08/03/15 13:24, Tudor Girba wrote: > >> I summarize below why I think fine grained configurations should be >> preferred to groups. >> > > Configurations are both about dependencies and how to make something work > together, and about how something is to be used. The granularity should be > so, that changes in underlying code lead to a minimum ripple effect in > configurations. That leads to a pressure for configurations to be as coarse > grained as possible. Groups allow configurations to be much more > coarse-grained than we could otherwise support. Fine grained configurations > expose implementation detail (structure) instead of an interface. I > consider groups to be first class citizens. If they are not currently, then > we should make them so. > I agree with you that we can benefit from a concept that shows the cohesion of what is being developed, but you did not reply to my argument. Groups are not an appropriate mechanism because we cannot easily manage them. If you can depend on a group it should follow that a group is like a configuration in the model. Add to that the idea of having different groups from one configuration depending on other groups from subconfigurations and you are in a complete mess that no tool is able to properly untangle. This is not the case now, and it has unwanted maintenance consequences. Until we find a mechanism that is indeed manageable, we should refrain from using it. > The fine grained configurations for GT make no sense at all to me. The same people are working on it and the parts need to change together. Incorrect. They have a different release and reuse life cycle. Pharo integrates only the Core configurations, while Moose integrates more. Things that are released together should be packaged together. The thing is that since we moved to fine grained configurations, we have less errors, the process is much easier and the tools easier to build. Cheers, Doru > > Stephan > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 9, 2015

[Pharo News] Article Series: Concerning Pharo

by Marcus Denker

Article Series: Concerning Pharo http://pharo.org/news/concerning-pharo Online: Now. Marcus

March 9, 2015

Re: [Pharo-users] smaller configurations vs groups [was Re: Pillar and GT tools in Pharo4]

by Stephan Eggermont

On 08/03/15 13:24, Tudor Girba wrote: > I summarize below why I think fine grained configurations should be > preferred to groups. Configurations are both about dependencies and how to make something work together, and about how something is to be used. The granularity should be so, that changes in underlying code lead to a minimum ripple effect in configurations. That leads to a pressure for configurations to be as coarse grained as possible. Groups allow configurations to be much more coarse-grained than we could otherwise support. Fine grained configurations expose implementation detail (structure) instead of an interface. I consider groups to be first class citizens. If they are not currently, then we should make them so. The fine grained configurations for GT make no sense at all to me. The same people are working on it and the parts need to change together. Stephan

March 9, 2015

Notebook/slideshow morph

by Torsten Bergmann

>So I imported my old code (it was one week of test first experience). >I can open a slideshow, create page, drop morph on it, mark a page as >template and navigate. Is there a way to save and reload the slide show. Like in the good old squeak days (TM) with a *.morph file? Would be a nice addition to recreate some of the presentation and multimedia features known from Squeak now also in Pharo. Thanks T.

March 9, 2015

Re: [Pharo-users] GitFileTree Version Numbering

by Martin BÃ¤hr

Excerpts from Thierry Goubier's message of 2015-03-09 07:06:41 +0100: > Le 09/03/2015 04:20, Sean P. DeNigris a Ã©crit : > > When copying MyPackage-Author-VersionNumber.mcz to an empty GitFileTree > > repository, VersionNumber is not considered, and it appears in the version > > browser as MyPackage-Author-1, which seems confusing. Could it keep the same > > VersionNumber? > > No ;) > > It takes ages to scan the version metadata contained in the git repository. why is that? it works when being read from an mcz file. how would reading it from git be any different? > This version metadata is wrong in some existing repositories (and > crashes the reader). wrong in monticello repos? > So GitFileTree rebuilts the version (number included) from scratch. what about just extracting the version from the very first commit? and then increment the number for all following commits? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

March 9, 2015

Re: [Pharo-users] GitFileTree Version Numbering

by Thierry Goubier

Le 09/03/2015 04:20, Sean P. DeNigris a Ã©crit : > When copying MyPackage-Author-VersionNumber.mcz to an empty GitFileTree > repository, VersionNumber is not considered, and it appears in the version > browser as MyPackage-Author-1, which seems confusing. Could it keep the same > VersionNumber? No ;) It takes ages to scan the version metadata contained in the git repository. This version metadata is wrong in some existing repositories (and crashes the reader). So GitFileTree rebuilts the version (number included) from scratch. Thierry

March 9, 2015