- Pharo-dev - lists.pharo.org

Re: [Pharo-project] WindowOrganizer integration problems

by laurent laffont

Another big thank you Gary ! In last TWM version there's a first (almost) working prototype of DockingWindowMorph. DockingWindowMorph new openInWorld. Now I need to make window/tab activation nice and fix a bug when the first tab is closed. Laurent. On Thu, Jul 7, 2011 at 12:09 PM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > ** > Hi Laurent > > The GroupWindowMorph does fill the window, however it has no layout policy > to the tab group within doesn't fill. > > In GroupWindowMorph initialize, either do a self changeProportionalLayout > or self changeTableLayout (making the fullFrame: bit redundant). > > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Wednesday, July 06, 2011 10:34 PM > *Subject:* [Pharo-project] WindowOrganizer integration problems > > Hi, > > As work from Gary about grouping windows has been integrated in 1.4, I try > to use it for TWM. > > If you load: > > Gofer it > squeaksource: 'TilingWindowManager'; > package: 'TWM'; > load. > > StandardWindow new > addMorph: GroupWindowMorph new fullFrame: (LayoutFrame fractions: (0@0corner: > 1@1)); > openInWorld. > > > You can drag and drop windows in the GroupWindowMorph to tab them. > > But I cannot find why GroupWindowMorph does not fill all the window....... > Gary ? > > Then I want to use GroupWindowMorph in a DockingBar. There's some initial > work in DockingWindowMorph but I'm stuck with the space fill problem. > > Cheers, > > Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ > Developer group: http://cara74.seasidehosting.st > >

July 7, 2011

Re: [Pharo-project] WindowOrganizer integration problems

by Gary Chambers

Hi Laurent The GroupWindowMorph does fill the window, however it has no layout policy to the tab group within doesn't fill. In GroupWindowMorph initialize, either do a self changeProportionalLayout or self changeTableLayout (making the fullFrame: bit redundant). Regards, Gary ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Wednesday, July 06, 2011 10:34 PM Subject: [Pharo-project] WindowOrganizer integration problems Hi, As work from Gary about grouping windows has been integrated in 1.4, I try to use it for TWM. If you load: Gofer it squeaksource: 'TilingWindowManager'; package: 'TWM'; load. StandardWindow new addMorph: GroupWindowMorph new fullFrame: (LayoutFrame fractions: (0@0 corner: 1@1)); openInWorld. You can drag and drop windows in the GroupWindowMorph to tab them. But I cannot find why GroupWindowMorph does not fill all the window....... Gary ? Then I want to use GroupWindowMorph in a DockingBar. There's some initial work in DockingWindowMorph but I'm stuck with the space fill problem. Cheers, Laurent Laffont - @lolgzs Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by Pavel Krivanek

On Thu, Jul 7, 2011 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote: > > > Hi Marcus, > > > > add this line to the initCore.st script on CI server: > > > > ActiveHand instVarNamed: #targetOffset put: 0@0. > > > Done and build started: > > https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/ Works! only one failing test left :-) -- Pavel

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by Pavel Krivanek

On Thu, Jul 7, 2011 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote: > > > Hi Marcus, > > > > add this line to the initCore.st script on CI server: > > > > ActiveHand instVarNamed: #targetOffset put: 0@0. > > > Done and build started: > > https://ci.lille.inria.fr/pharo/job/Pharo%ckages now have already > two sets of du20Kernel%20Reload/<https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/> > > > > this will fix the testTargetPoint. The second and last failing tests is > related to compressed unicode tables in the kernel image. I will prepare the > code that will regenerate this tables. > > > > The second option is to disable call of privShrinkUnicodeTables method in > privShrinkingProcess. The resultant kernel and gofer images will be bigger. > The question is if we will shrink this tables by default. > > I am in general not happy how resources are right now stored in the > image... the only way right now is to either have them just there as > objects, non-recreateble or people store stuff (fonts, bitmaps) > as strings (or ByteArrays) in methods. This is not nice... but of course MC > can store it and so its the only option. > > We should think about having an in-image, virtual file-system with all the > static stuff... maybe this could even be per package and serialized with MC > as part of the package? > It is quite easy to extend data stored in MC packages, for example for the original versions of the KernelImage I extended packages with preamble and postcript files. The only problem was with versioning of this extensions. Life would me more easy if MC would provide general interface for versioning of all kinds of files in the package. > The MC packages now have already two sets of duplicated data: source (in > the .st file) and the MC History data... which should not be underestimated: > MC wastes right now 4MB of 13.5 MB in 1.4, > In addtion, the fact that we have to wirite to .changes when loading a > package is far from nice... it would be better of packages would be > self-contained and the system would get the source > from them. > Interesting idea. The good start would be introduction of general pluggable source managers. -- Pavel > > Marcus > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

July 7, 2011

Re: [Pharo-project] reloaded Core failing tests

by Marcus Denker

On Jul 6, 2011, at 10:56 PM, Pavel Krivanek wrote: > Hi Marcus, > > add this line to the initCore.st script on CI server: > > ActiveHand instVarNamed: #targetOffset put: 0@0. > Done and build started: https://ci.lille.inria.fr/pharo/job/Pharo%20Kernel%20Reload/ > this will fix the testTargetPoint. The second and last failing tests is related to compressed unicode tables in the kernel image. I will prepare the code that will regenerate this tables. > > The second option is to disable call of privShrinkUnicodeTables method in privShrinkingProcess. The resultant kernel and gofer images will be bigger. The question is if we will shrink this tables by default. I am in general not happy how resources are right now stored in the image... the only way right now is to either have them just there as objects, non-recreateble or people store stuff (fonts, bitmaps) as strings (or ByteArrays) in methods. This is not nice... but of course MC can store it and so its the only option. We should think about having an in-image, virtual file-system with all the static stuff... maybe this could even be per package and serialized with MC as part of the package? The MC packages now have already two sets of duplicated data: source (in the .st file) and the MC History data... which should not be underestimated: MC wastes right now 4MB of 13.5 MB in 1.4, In addtion, the fact that we have to wirite to .changes when loading a package is far from nice... it would be better of packages would be self-contained and the system would get the source from them. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 7, 2011

[Pharo-project] [PBE-Spanish] Status update 2011-07-06

by NicolÃ¡s Paez

Hello everyone, Here is the weekly update of the Spanish translation of Pharo By Example book. During this past week, we didn't do any important progress, we still have 2 chapters under translations. We started the review process and we have publish a new preview containing 9 chapters. You can download this preview from this location: https://gforge.inria.fr/frs/download.php/28711/PBE1-Spanish-Draft-2011-07-0… Regards, Nico Saludos! Nico. blog: nicopaez.wordpress.com

July 7, 2011

Re: [Pharo-project] [Jenkins] State of transition Hudson -> Jenkins

by Mariano Martinez Peck

Thanks Marcus for the push. The to-dos look awesome :) On Wed, Jul 6, 2011 at 11:50 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > State of transition Hudson -> Jenkins > ============================= > > We are slowly (step by step) moving builds from Hudson to Jenkins. > > the last days e.g. Coral (the scripting engine), RPackage, Nautilus... > > https://ci.lille.inria.fr/pharo/ > > The largest thing to move will be the VM autobuilt... that will be done > later. > > Jean Baptiste Arnaud started with a setup for regression testing. > https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20Regression%20Tests/ > > This means > "doing something slow" > "run all tests" > get new image > "doing something other" > "run all tests" > > The idea here is that this will be used for the following > > -> recompile the image > -> decompile and recompile the decompiled code > -> pretty print > -> condense sources > -> condense changes > .... > > > On the TODO list we have > > -> test the compiled VMs by running all tests on all plattforms > -> update the One-click build script with the last good VM > -> update the VM used to do everything with the self-build vm > > The goal is of course to have that what we release be build completely > without human intervention, after every commit (either VM source or Image > level change). > > In addtion, this setup will be available for others to use. This way > students > can easily clone the VM source and set up Continuous Integration for their > research Fork. This will than make it far far easier for people to invent > cool stuff > that needs VM changes, like e.g. this: > > http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf > or > > http://rmod.lille.inria.fr/archives/papers/Arna10a-Tools2010-ReadOnlyExecut… > > The problem right now is that all the code is "somewhere" and just picking > up where the student left > is a huge amount of work... with Git and autbuild, this will get much much > better. > (and it simplifies the life of the student a lot... autobuild, easy to > track changes in the upstream...) > > JB already successfully builds his Handle VM: > > https://pharo-ic.lille.inria.fr/hudson/job/Handles/ > > So we are getting there. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Mariano http://marianopeck.wordpress.com

July 6, 2011

[Pharo-project] WindowOrganizer integration problems

by laurent laffont

Hi, As work from Gary about grouping windows has been integrated in 1.4, I try to use it for TWM. If you load: Gofer it squeaksource: 'TilingWindowManager'; package: 'TWM'; load. StandardWindow new addMorph: GroupWindowMorph new fullFrame: (LayoutFrame fractions: (0@0corner: 1@1 )); openInWorld. You can drag and drop windows in the GroupWindowMorph to tab them. But I cannot find why GroupWindowMorph does not fill all the window....... Gary ? Then I want to use GroupWindowMorph in a DockingBar. There's some initial work in DockingWindowMorph but I'm stuck with the space fill problem. Cheers, Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ Developer group: http://cara74.seasidehosting.st

July 6, 2011

[Pharo-project] reloaded Core failing tests

by Pavel Krivanek

Hi Marcus, add this line to the initCore.st script on CI server: ActiveHand instVarNamed: #targetOffset put: 0@0. this will fix the testTargetPoint. The second and last failing tests is related to compressed unicode tables in the kernel image. I will prepare the code that will regenerate this tables. The second option is to disable call of privShrinkUnicodeTables method in privShrinkingProcess. The resultant kernel and gofer images will be bigger. The question is if we will shrink this tables by default. -- Pavel

July 6, 2011

[Pharo-project] [ANN] Fuel version 1.5 released (bis)

by Martin Dias

Hi. I am happy to announce the new release version 1.5. At the end of this message is the list of changes. Fuel is a binary serialization system for Smalltalk that provides extremely fast deserialization. More information on our home page<http://rmod.lille.inria.fr/web/pier/software/Fuel> . In next days we will update it. We have much more to show especially in benchmarks section. We have many ideas and new issues<http://code.google.com/p/fuel/issues/list>to keep working on Fuel. You can download this version in Pharo with: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.5') load. Again, I have to thank ESUG for sponsoring me for Fuel development through the SummerTalk program. Changes: - Initialize instances after materialization implementing #fuelAfterMaterialization. - Ignore transient instance variables overriding #fuelIgnoredInstanceVariableNames. - Limit serialization progress bar to update at most once every 250 milliseconds. - Traits are serialized and materialized as a regular objects ( http://code.google.com/p/fuel/issues/detail?id=59) - Removed mappers system cache (Eliot). - Many new tests. - Benchmarks: compare Fuel against StOMP, SRP, SIXX, Magma, EsAndEm and Fuel with progress bar. - Benchmarks: new samples, scripts, and CSV exporter. - Benchmarks: measure serialization stream size. - Removed some redundant #fuelAccept:. - Several aesthetic changes in protocols, categories and comments. - Now #materialize answers the materialized root. - Removed special cluster for HashedCollection.Now #rehash is sended via #fuelAfterMaterialization. - MethodContext serialization does not serialize temps ( http://code.google.com/p/fuel/issues/detail?id=61) - Classes and Traits now serialize its environment (testCreateWithSmalltalkGlobalsEnvironment). - Fixed serialization of non-octet characters (testCharacter). - Fixed a bug serializing the system dictionary. FLWellKnownObjectsCluster handles it. (testSmalltalkGlobals). - Fixed a bug serializing class variables (testClassVariable). - Fixed a bug when serializing a collection with size greater than 1^16 with repeated elements inside. - Fixed testTwoCompiledMethodsReferencingSameClassVariable. - Optimization: instanceIndexes are directly created with the exact size (Henrik).

July 6, 2011