- Pharo-dev - lists.pharo.org

[Pharo-project] Helping with Athens development
by dimitris chloupis Nov. 23, 2012

Nov. 23, 2012

So after diving in common lisp and take a look at various alternative I decided that Pharo is the best place for me to start for my Ephestos project. The first thing that got my attention is Athens , it seems to be very close to my own goal for Ephestos. So my question is how may I help Athens involve by contributing code to it ? Are there specific features I can work on ? The first part of my Ephestos project I call it Morpheas and its basically a GUI API based on morphic specialised on customised guis, meaning guis that do not look native . Athens seems a good library to base Morpheas on, so I am actually interested in expanding it. In the future I would also like to port Athens to opengl , but if cairo is fast enough for me, I may avoid it and instead focus more on porting Morphic to Athens. So my post here is to clarify the way I can contribute to Athens . I want my project Ephestos to be a contribution to the existing Pharo image and offer more GUI widgets, maybe a gui designer and some more graphic and audio tools. I think that Athens can be the base for my project so naturally I want to contribute.

4 10

Re: [Pharo-project] Helping with Athens development
by Fernando Olivero Nov. 23, 2012

Nov. 23, 2012

For now, Athens uses the software renderer of Cairo to draw into a Cairo Surface. We get it back to the Pharo, buy telling a Form to load the bits of the Cairo surface. Would be nice to have another renderer for Athens, besides Cairo, to use a hardware accelerated renderer. OpenGL backend for Athens would be great. NBOpenGL is already there. So it would a matter of having another AthensCanvas, and AthensSurface that uses OpenGL to draw. Yet, the current scheme is fast enough! So i don't know wether this is a priority. Fernando On Fri, Nov 23, 2012 at 12:11 PM, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: > So after diving in common lisp and take a look at various alternative I > decided that Pharo is the best place for me to start for my Ephestos > project. The first thing that got my attention is Athens , it seems to be > very close to my own goal for Ephestos. So my question is how may I help > Athens involve by contributing code to it ? > > Are there specific features I can work on ? The first part of my Ephestos > project I call it Morpheas and its basically a GUI API based on morphic > specialised on customised guis, meaning guis that do not look native . > Athens seems a good library to base Morpheas on, so I am actually > interested in expanding it. > > In the future I would also like to port Athens to opengl , but if cairo is > fast enough for me, I may avoid it and instead focus more on porting > Morphic to Athens. > > So my post here is to clarify the way I can contribute to Athens . I want > my project Ephestos to be a contribution to the existing Pharo image and > offer more GUI widgets, maybe a gui designer and some more graphic and > audio tools. I think that Athens can be the base for my project so > naturally I want to contribute. >

1 0

[Pharo-project] Metacello Why symbolicversion and not simply tagged version:?
by StÃ©phane Ducasse Nov. 23, 2012

Nov. 23, 2012

Dale in my goal to reduce the complexity of metacello, I'm wondering why symbolic versions could not be expressed as version: because version: #stable version: #development are symbolic versions and there is no clash possible with version: '1.1' Stef

3 8

[Pharo-project] pharo-2.0-tests Â» win - Build # 491 - Failure!
by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr Nov. 23, 2012

Nov. 23, 2012

1 0

[Pharo-project] sources location
by Pavel Krivanek Nov. 22, 2012

Nov. 22, 2012

Hi, the packages for Linux distribution have troubles to work with *.sources files. Currently the image is looking for sources files in this order: - vm directory - image directory - working directory There are packages for the virtual machine and the image. All in latest versions. The sources file should be part of the image package. But in that case it must copy the sources file into the VM location (and that may be complicated because of version string in the vm path). In case that you update the image package and the image uses newer sources version, the old one should be deleted. There are several more or less bad solutions: - copy the sources file next to the image and changes file when the new custom image is being created. Very space consuming - create symlink next to the image and changes file. Bad because in case you update image package the old source file is deleted - collect all old source files in the vm package. Bad because you do not know what image version will be used - collect all old source files in the image package. Very strange and you have to place the sources files somehow next to the virtual machine - have standalone package for every source file and place symlinks next to the image file when a new custom image is created So as you may see, we really need some next way how to resolve sources files location. In ideal world we would be able to read it from a system variable. The user will have in his home all source files that images he owns use. But we do not have VM support for that. Cheers, -- Pavel

2 1

[Pharo-project] [update 2.0] #20416
by Marcus Denker Nov. 22, 2012

Nov. 22, 2012

20416 ----- Issue 7032: DummySystemProgressItem is used only by UIManger --> move there http://code.google.com/p/pharo/issues/detail?id=7032 Issue 7016: repackage restoreAllNotifications http://code.google.com/p/pharo/issues/detail?id=7016 Diff information: http://ss3.gemstone.com/ss/Pharo20/UIManager-MarcusDenker.92.diff http://ss3.gemstone.com/ss/Pharo20/SystemProgress-MarcusDenker.5.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.748.diff http://ss3.gemstone.com/ss/Pharo20/System-PragmaCollector-MarcusDenker.11.d… http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1257.diff -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] smalltalkhub and project ownership
by Torsten Bergmann Nov. 22, 2012

Nov. 22, 2012

>We should keep in mind that Smalltalkhub is still under development :) > >And our poor Nicolas is running out of time (too many things to do) :D Sorry for reminding on this: I see a clear downside of all this since smalltalk hub is currently very concentrated on one person and his time schedule. I'm sure the next version of SmalltalkHub will provide many new wanted features and it is a great system and service for Pharo. On the other side now two communities waiting for Nicolas to bring something more awesome (see Amber [1]) ;) Yes SH is open source - but it would help if the impatient community would be able to participate in one or the other way or follow this new development... A ConfigurationOfSmalltalkHub would be a start ... Bye T. [1] http://forum.world.st/A-few-days-with-Nicolas-td4638661.html

2 1

Re: [Pharo-project] I don't agree with DummyXXX
by Fernando Olivero Nov. 22, 2012

Nov. 22, 2012

I totally agree. Dummy does not tell me about the class. Are there just 3 uses of Dummy in the core? We should either use Null or use a specific prefix always, so its form a consisten pattern. DummyUIManager -> NullUIManager Fernando On Wed, Nov 21, 2012 at 4:34 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > From what I understand, Dummy means something different. I have using that > for class names. More accurate names can be found. > I would rename: > > DummyUIManager -> HeadlessUIManager > DummySystemProgressItem -> NullSystemProgressItem > DummySoundSystem -> NullSoundSystem > > what do you think? do you have better names? > > -- > Mariano > http://marianopeck.wordpress.com > >

10 13

Nov. 22, 2012

Stef

8 20

Nov. 22, 2012

Hi dale I implemented a little tool that - create a kind of specification (version, package, repo) for all the packages reachable from a configurationOf (see below method method packagesAndAssociatedRepositoriesFromConfigurationRecord ) It generates a script looking as follows: script3 ^ #( #('ConfigurationOfFame-TudorGirba.5.mcz' 'http://www.squeaksource.com/Fame/' 'ConfigurationOfFame' ) #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz' 'http://www.squeaksource.com/MooseAlgos/' 'ConfigurationOfMooseAlgos' ) #('ConfigurationOfGlamour-TudorGirba.98.mcz' 'http://www.squeaksource.com/Glamour/' 'ConfigurationOfGlamour' ) #('ConfigurationOfDSM-AlexandreBergel.56.mcz' 'http://www.squeaksource.com/dsm/' 'ConfigurationOfDSM' ) #('ConfigurationOfKumpel-AlexandreBergel.3.mcz' 'http://www.squeaksource.com/Kumpel/' 'ConfigurationOfKumpel' ) #('ConfigurationOfSmallDudâ¦â¦â¦â¦.) - I keep the order given by Metacello. I extract the information as follows: packagesAndAssociatedRepositoriesFromConfigurationRecord: aConfigurationRecord "| record | record := ((Smalltalk globals at: #ConfigurationOfMoose) project version: 'default') ignoreImage: true; record. self packagesAndAssociatedRepositoriesFromConfigurationRecord: record " | pkgs | pkgs := OrderedCollection new. aConfigurationRecord loadDirective packageDirectivesDo: [:directive | pkgs add: {directive spec name, '*'. (self removeCache: directive spec workingCopy repositoryGroup repositories) anyOne locationWithTrailingSlash} ]. ^ pkgs - then I try to load the package as follows: flatVersion47: spec <version: '4.7-flat'> spec for: #common do: [ self populateSpec: spec with: self script3 ] I load them doing (ConfigurationOfMoose project version: '4.7-flat') load Now It does not work because after fetching all the packages, the system complain that some classes that will be loaded later are not present. I imagine that you use Gofer and that Gofer does not use the merging semantics of MC over multiple projects (that you can have multiple package in any order and that the classes get loaded - as I use it for the scriptLoader and below). - before I was doing it by doing a diff between the pharo package and the one loaded and I was loading the specification after installing the repository and the working copies using the MCVersionLoader and it worked I could reload completely Moose! load: aCollectionOfPackageString "self new load: #( 'Famix-C-TudorGirba.15' 'Famix-Core-NicolasAnquetil.201'))" | loader | loader := MCVersionLoader new. (self newerVersionsIn: aCollectionOfPackageString) do: [ :fn | loader addVersion: (self loadVersionFromFileNamed: fn). (Delay forSeconds: 2) wait.] displayingProgress: 'Adding versions...'. loader hasVersions ifTrue: [loader load]. So my question is - Does the packageDirectivesDo: provide an order that I can use to load package with the gofer-load on project at a time? May be my code does not keep the same order but I payed attention to this point. I will check that further. - may be I could extend Gofer to support multiple project merge loading. So right now I'm stuck and this is sad because freezing a complex configuration is really needed. Stef

3 7