- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by Torsten Bergmann

The reason is simple: when I wrote the config browser there was no such additional description on the configs itself and one would have to load the config into the image first. Think of 2000 config's (note each is a package) loading in the future when the config browser opens. This will take ages. I think this is not good since the app should be responsive. Maybe a "show details" button helps when the package is selected. I would rather see: 1. Either a simple hosted seaside app "Pharo Store" that one can use to register a config for a specific pharo version (similar like squeakmap) maybe directly from the STHub interface with description, ... This app can be queried by the config browser (JSON/XML/Fuel/...) to display infos on the package, maybe also a rating about downloads, ... 2. Or a general mechanism that loads the configs, runs tests and if OK provides them for the config browser as "yes these config really work" Bye T.

Dec. 8, 2013

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by Sven Van Caekenberghe

On 08 Dec 2013, at 09:31, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > really simple 4 class side methods OK, I see that this can be in Pier syntax. No problem for me, but that does mean that weâll need a Pier parser and renderer in the base image, no ? Else tools will not be able to show this, right ?

Dec. 8, 2013

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by StÃ©phane Ducasse

On Dec 7, 2013, at 11:46 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Ok. I am taking a look now, still trying to figure out how Spec manage the layout offsets. Should I commit changes as a Slice in http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main ? Yes with a bug entry. I will be great liek that I can browse my configruation :) Stef > > HernÃ¡n > > > 2013/12/7 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Dec 7, 2013, at 8:44 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > Is there a specific reason why this was not implemented? Is someone working on this? > > We added catalog metadata to configuration now > - the tools should take into account about that > - people should add such metadata to their configuration > > If you modify the package browser to present description it will be in the system > > > Stef > > > See the "Perl Package Manager" for example. > > > > When you launch it, takes some time to update but each item displays the Details and you have an Abstract colum. > > > > Cheers, > > > > HernÃ¡n > > > > > > >

Dec. 8, 2013

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by StÃ©phane Ducasse

>> We added catalog metadata to configuration now >> - the tools should take into account about that >> - people should add such metadata to their configuration >> >> If you modify the package browser to present description it will be in the system > > Stef, what is the spec, the API, is there an example config with description in the image already ? really simple 4 class side methods catalogDescription ^ 'Soup is a frameworks for scrapping HTML. It offers a simplified query mechanism to abstract over the XML and HTML structures of a document.' catalogKeywords ^ #(HTML web query scrapping Soup XPath) catalogChangeLog ^ '- Version 1. 4 21/02/2013 migrated to SmalltalkHub [[[ (ConfigurationOfSoup project version: ''1.4'') load ]]] - Version 1.3 adding better stable version. [[[ (ConfigurationOfSoup project version: ''1.3'') load ]]] ' catalogKeyClassesAndExample ^ 'It is composed of some keys classes: - ==SoupElement== is the root of elements that are extracted during the parsing of an HTML document. Contrary to traditional HTML Parser, Soup produces a limited set of elements which approximate the HTML elements but supports querying and extracting information. - Soup. ==Soup== is the main public class of the package. It is the class to interact with as shown by the tests. The best way to get started is to get a soup of html elements using ==Soup class>>fromString:== as follows: [[[ Soup fromString: ''http://www.bedetheque.com/album-105582-BD-Atomium-Express.html'' asUrl retrieveContents ]]] Tests of the ==Soup== class are the place to start to learn the API.' have a look at SOUP

Dec. 8, 2013

Re: [Pharo-dev] Pharo magic

by S Krish

Smalltalk has always been the crucible of inventions... http://www.tomshardware.com/news/alan-kay-steve-jobs-ipad-iphone,10209.html Pharo can take its rightful place in near future, amongst Java and C# to give a credible choice for an interactive development platform. Dynabook with Pharo .. as Kay imagined..? or adapted to be mass produced. I like the thought in mash-up of objects rather than standalone apps in an App Store comment. On Sat, Dec 7, 2013 at 3:22 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 07 Dec 2013, at 00:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > This seems to be a good place to introduce myself. > > > > Welcome! > > > My Name is Nicolai Hess, > > I follow the squeak (and pharo) community for some years (~10). > > (Not as an *active* member in that time, but a little bit more the last > days:-) > > I am a software developer, most time working with c++ and java. > > Every time I start to dive into smalltalk world (again), > > even if all i have done are bugreports or small bugfixes, > > it impressed me how much more fun it makes. > > > Very nice small fixes :-) Thanks a lot for those! > > > Looking at smalltalks history I was always deeply impressed about all > > its development and *inventions*. > > (And a bit sad, it is not as recognized as it > > could be, and seeing how others again reinventing these things.) > > > > Yes, and it is important that we move the system forward so we are not > out-invented > by the worldâ¦ > > Marcus > > >

Dec. 8, 2013

[pharo-project/pharo-core]

by GitHub

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

Dec. 8, 2013

[pharo-project/pharo-core] c42451: 30632

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: c4245121e7de93f2907763b53d6eb65e4db029e6 https://github.com/pharo-project/pharo-core/commit/c4245121e7de93f2907763b5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-07 (Sat, 07 Dec 2013) Changed paths: M CodeImport.package/MissingClassError.class/instance/actions/defineClass.st M KernelTests.package/BehaviorTest.class/instance/tests/testCanUnderstand.st M Metacello-PharoCommonPlatform.package/MetacelloPharoCommonPlatform.class/instance/reflection/copyClass_as_inCategory_.st M NativeBoost-Core.package/NativeBoost.class/class/debugger support/tryRunNativeCode_for_withArgs_.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/literals/testScaledDecimalLiterals.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script287.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30632.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/SmalltalkImage.class/instance/compiler/compilerClass.st M Text-Core.package/TextDoIt.class/instance/evaluating/actOnClick_for_in_editor_.st M Text-Core.package/TextPrintIt.class/instance/as yet unclassified/actOnClick_for_in_editor_.st M Zinc-HTTP.package/ZnReadEvalPrintDelegate.class/instance/private/evaluate_.st Log Message: ----------- 30632 12372 remove all direct references to Compiler https://pharo.fogbugz.com/f/cases/12372 12357 Failing test: #testCanUnderstand https://pharo.fogbugz.com/f/cases/12357 http://files.pharo.org/image/30/30632.zip

Dec. 8, 2013

Re: [Pharo-dev] It would be too expensive to add a description for packages in Configuration Browser?

by Chris Muller

> This is such a gaping hole in Monticello. I hope Pharo and Squeak can I don't see it as a Monticello responsibility. MC should remain concerned solely with SCM. Configuration should be handled one layer above it. Whether by Metacello, SqueakMap, Installer, PackageInfo, Universes or something else of the configurators choice. > implement this compatibly. I hope the repository web interfaces can display > the latest version of the package description too. Which package do you mean by "the package"? Currently, package version comments _are_ already displayed by the web-interface. (So, this supports that we should not let the SCM tool dual as a Configurator).

Dec. 8, 2013

Re: [Pharo-dev] Using TreeModel>>selectAll

by Martin Dias

aha! thanks MartÃn On Sat, Dec 7, 2013 at 10:33 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > roots := #(1 2 3) collect: [ :e | TreeNodeModel new content: e ; yourself ]. > > TreeModel new > roots: roots; > multiSelection: true; > openWithSpec. > > roots third > selected: true; > takeHighlight > > Ben > > On 07 Dec 2013, at 05:44, Martin Dias <tinchodias(a)gmail.com> wrote: > > ouch! thanks Ben. > > Another related question: is there any way of selecting an arbitrary > item? I tried (among others) with: > > TreeModel new > roots: #(1 2 3); > multiSelection: true; > openWithSpec; > selection: 3 > > without success. > > Cheers, > MartÃn > > > > On Thu, Dec 5, 2013 at 4:17 PM, Benjamin > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > > your tree here is single selection so it will not work > > TreeModel new > roots: #(1 2 3); > multiSelection: true; > openWithSpec; > selectAll > > Ben > > On 05 Dec 2013, at 15:38, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi, > > I'm not sure how this method should be used. I tried in different > ways, for example: > > TreeModel new > roots: #(1 2 3); > selectAll; > openWithSpec > > But always the items are unselected. Is it a bug? or I didn't find the > way to use it? > > Thanks, > MartÃn > > > >

Dec. 8, 2013

Re: [Pharo-dev] Pharo 3 package dependencies visualization

by HernÃ¡n Morales Durand

Hi Frank, I just removed the Kernel from the package list on purpose because it would be confusing with too many lines around. Anyway you can include it if you like, this is the script to generate the graph: | packages all allNames | packages := #('AST' 'Announcements' 'AsmJit' 'Athens' 'Balloon' 'ClassOrganizer' 'CodeImport' 'Compiler' 'EventModel' 'FileSystem' 'Files' 'FreeType' 'Fuel' 'Gofer' 'HelpSystem' 'Keymapping' 'Manifest' 'Metacello' 'NECompletion' 'Ring' 'System' 'Text' 'Tools'). allNames := RPackageOrganizer default packageNames. all := (packages collect: [: pkgName | allNames select: [ : pkg | pkg asString beginsWith: pkgName ] ] ) gather: [ : c | c ]. (PDGraphPackageAnalyzer onPackagesNamed: all) save: 'pharo-3.dot'. A cycle (red) between two packages is shown when any kind of inheritance, reference or extension is found between. Cheers, HernÃ¡n 2013/12/7 Frank Shearar <frank.shearar(a)gmail.com> > On 7 December 2013 20:21, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: > > You could be interested in viewing some circular dependencies (red > lines) in > > Pharo 3 generated with GraphViz/PackageDependencies using > > http://www.smalltalkhub.com/#!/~hernan/GraphViz > > > > > https://drive.google.com/file/d/0B7XMfmjGRcXASHB1c2xLSFdLR2s/edit?usp=shari… > > > > downloaded with > > > > $ wget -O- get.pharo.org/30+vm | bash > > Cool! I suspect the graph shows just the cycles and the neighbours of > packages involved in the cycles? Because I can't find any Kernel > packages, and there are a bunch of packages that have "no" > dependencies. All packages _must_ have a dependency on _something_, > because all classes ultimately inherit from Object, which obviously > sits in a package. > > frank > > > Cheers, > > > > HernÃ¡n > > > >

Dec. 8, 2013