November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fuel: fix for Squeak trunk

by Max Leske

So far we donât have a public inbox and Iâm not too familiar with STHub and read/write permissions. Concerning your suggestion from the other thread a public inbox would certainly make sense though. Iâll let you know what we can come up with (STHub seems to be down right now so I canât even give you access right now. But you can send me your fix through mail). Max On 02.11.2013, at 09:46, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Thanks, and is there a public .mcz inbox, or does it require special rights? > > > 2013/11/2 Max Leske <maxleske(a)gmail.com> > The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ > > On 01.11.2013, at 22:42, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > I have an easy fix for Fuel on Squeak trunk. > > It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... > > Is there a dedicated bug tracker? > > What is the preferred procedure? > > > > Nicolas > > >

Nov. 2, 2013

Re: [Pharo-dev] Update Fuel documentation

by Max Leske

Ok. Weâll figure something out. On 02.11.2013, at 09:44, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > No, it's not released. > But we value continuous integration, and non regression on a set of supported package. > And Fuel is one of the supported packages (http://build.squeak.org/job/ExternalPackage-Fuel/) > > As I see it, Squeak trunk evolutions that break supported package deserve support from Squeak developers. > So the idea would be to open a new compatibility version and grant some rights to interested developpers, at least in inbox. > > > 2013/11/2 Max Leske <maxleske(a)gmail.com> > Thanks Nicolas. Weâll update the docs and fix the configuration. > > Has 4.5 been released? We had decided to wait with support for 4.5 until it was released to prevent repetitive work. If 4.5 has indeed been released weâll of course add support for 4.5. > > Cheers, > Max > > > On 01.11.2013, at 21:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> This page http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… has obsolete information, at least for Squeak installation. >> >> This is because ConfigurationOfFuel-MaxLeske.178 still points to old repository http://ss3.gemstone.com/ss/Fuel.html which has been drained... >> ConfigurationOfFuel-MartinDias.209 should be a better starting point. >> >> In latest Squeak trunk there is another problem: lack of squeak4.5.x support both in ConfigurationOfFuel and MetacelloSqueakPlatform>>defaultPlatformAttributes. >> But it's another problem, not related to documentation > >

Nov. 2, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

and here is the strange MNU that I was talking about earlier here is the full stack Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>acceptDroppingMorph:event:inMorph: MorphTreeMorph>>acceptDroppingMorph:event: MorphTreeMorph(Morph)>>handleDropMorph: DropEvent>>sentTo: MorphTreeMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDropEvent:with: MorphicEventDispatcher>>dispatchEvent:with: MorphTreeMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDropEvent:with: MorphicEventDispatcher>>dispatchEvent:with: PanelMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDropEvent:with: MorphicEventDispatcher>>dispatchEvent:with: NautilusWindow(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDropEvent:with: MorphicEventDispatcher>>dispatchEvent:with: WorldMorph(Morph)>>processEvent:using: WorldMorph(Morph)>>processEvent: HandMorph>>sendEvent:focus:clear: HandMorph>>sendEvent:focus: HandMorph>>dropMorph:event: HandMorph>>dropMorphs: in Block: [ :m | ... Array(SequenceableCollection)>>reverseDo: HandMorph(Morph)>>submorphsReverseDo: HandMorph>>dropMorphs: HandMorph>>handleEvent: HandMorph>>processEvents WorldState>>doOneCycleNowFor: in Block: [ :h | ... Array(SequenceableCollection)>>do: This one happens when I bring up the halos and try to move the morph around.Morphs gets deleted because of MNU. Note it does not happen with just my Class (Hyperion) it happens with any morph using Athens. Hyperion in this case is a partial copy of the AthensDemoMorph. As always I am using Pharo 3 (Latest update: #30534) . On Fri, Nov 1, 2013 at 7:14 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 1 November 2013 14:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > >> Ok now the explanation :) >> Spec changed recently in 30. >> >> > then i need help on that.. what is needs to be changed. > btw, i noticed that monticello configuration browser also having problems > with spec. > > >> Stef >> >> >> Again I am following Igor instructions, loaded Athens-Tutorial from >> smalltalkhub , opened a new workspace, AthensTutorial open. I am using a >> pharo 3 that downloaded just yesterday. (Pharo3.0 Latest update: #30532) >> >> here is the full stack >> >> AthensViewMorph(Object)>>doesNotUnderstand: #layout: >> SpecInterpreter>>actionToPerformWithSelector:arguments: >> SpecInterpreter>>performNextSelectorAndIncrementIndex >> SpecInterpreter>>interpretASpec:selector: >> SpecInterpreter>>interpretASpec:model:selector: >> SpecInterpreter class>>private_interpretASpec:model:selector: >> SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each | >> self class private_interpretASpec: each ...etc... >> Array(SequenceableCollection)>>collect: >> SpecInterpreter>>performNextSelectorAndIncrementIndex >> SpecInterpreter>>interpretASpec:selector: >> SpecInterpreter>>interpretASpec:model:selector: >> SpecInterpreter class>>private_interpretASpec:model:selector: >> SpecInterpreter class>>interpretASpec:model:selector: in Block: [ result >> := self private_interpretASpec: aPresente...etc... >> BlockClosure>>ensure: >> SpecInterpreter class>>interpretASpec:model:selector: >> SpecInterpreter class>>interpretASpec:model: >> AthensTutorial(ComposableModel)>>buildWithSpecLayout: >> MorphicWindowAdapter>>addModelIn:withSpecLayout: >> MorphicWindowAdapter(AbstractAdapter)>>update:with: >> WindowModel(Object)>>changed:with: in Block: [ :aDependent | aDependent >> update: anAspect with: ...etc... >> DependentsArray>>do: >> WindowModel(Object)>>changed:with: >> WindowModel>>addModelIn:withSpecLayout: >> WindowModel>>buildWithSpecLayout: >> WindowModel>>openWithSpecLayout: >> AthensTutorial(ComposableModel)>>openWithSpecLayout: >> AthensTutorial(ComposableModel)>>openWithSpec: >> AthensTutorial(ComposableModel)>>openWithSpec >> AthensTutorial class>>open >> UndefinedObject>>DoIt >> >> Is that enough ? >> >> I am also getting another error from Athens from time to time, I will >> have to remember to capture it cause it appears randomly. >> >> >> On Fri, Nov 1, 2013 at 1:42 PM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> Igor I got Athens-Tutorial but it gives me a MNU: >>> AthensViewMorph>>layout: >>> >>> >>> strange tell us more. >>> You know >>> which image >>> â¦. >>> >>> Stef >>> >>> >>> >>> >>> On Fri, Nov 1, 2013 at 10:23 AM, kilon alios <kilon.alios(a)gmail.com>wrote: >>> >>>> ShivaVG looks definitely as a way to ease the pain of porting to >>>> OpenGL. >>>> >>>> Some notes on the matter. The Cairo backend for OpenGL is opengl but >>>> yet its not opengl. What it does is render cairo as a opengl texture. >>>> OpenGL true power is in the shaders so you dont get the kind of hardware >>>> acceleration you would expect. >>>> >>>> Speewise as surprising this may sound opengl is not the ideal option, >>>> because opengl is mainly 3d orientated. The ideal solution from what I have >>>> seen would be something like CUDA or OpenCL, that give direct access to the >>>> GPU cores and allow you to do any kind of computation thus liberation from >>>> the restrictions of APIs. For example Blender takes advantage of both >>>> Opengl and CUDA , the CUDA renderer is phenomenal better because of its >>>> flexibility. >>>> >>>> The problem however is that all that are very technical and it takes >>>> quite some dedication to implement. >>>> >>>> A reason why I abandoned opengl as an idea is that I came to realise >>>> that Cairo was already fast enough for my needs. But I still keep that door >>>> open for the distant future, ShivaVG with OpenCL would be awesome for >>>> really intensive GUIs and complex Graphics and definitely would love to >>>> give it another try eventually. >>>> >>>> >>>> On Fri, Nov 1, 2013 at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: >>>>> >>>>>> Not sure to fully understand the problem. In what ShivaVG would solve >>>>>> a situation better than with Athens? If I understand well, a then working >>>>>> with Cairo uses the hardware acceleration right? >>>>>> What is it not enough for you need? >>>>>> >>>>>> First, OpenVG is more complete and i would say thoroughly designed >>>>> API than Cairo. >>>>> Second, i don't want to go Athens -> Cairo -> OpenGL >>>>> if i can do directly Athens->OpenGL. >>>>> Putting extra dependency out of the loop is advantageous, OpenGL is >>>>> widely supported industry standard, which today you can find even on >>>>> portable devices, while you cannot say same about Cairo. >>>>> (not mentioning avoiding costs of having multiple layers to get to >>>>> the hardware). >>>>> >>>>> ShivaVG implements OpenVG API using OpenGL, since OpenVG is vector >>>>> graphics framework >>>>> it can serve as a good source to look how to implement OpenGL backend >>>>> for Athens. >>>>> >>>>> >>>>>> Alexandre >>>>>> >>>>>> > Le 31-10-2013 Ã 19:16, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : >>>>>> > >>>>>> > I cannot say, of course, how it would be for you, but there is >>>>>> ShivaVG[1] open-source >>>>>> > opengl implementation of OpenVG, more or less feature-complete, >>>>>> > so all what is needed is to port this code from C to smalltalk. >>>>>> > Or if not for porting, but using as a source of insights how to >>>>>> implement it. >>>>>> > I think it is fairly doable. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Nov. 2, 2013

Re: [Pharo-dev] smalltalkhub is down

by Marcus Denker

Yes, and exactly as last week I can not do *anything*. And everyone who could do something is in Argentina, I guess sleeping right now. We really need to change this. And best before we have exactly the same next saturday, again. (Sadly, as said, I can do *absolutely* nothing, I can not even do anything to change that I can do nothing.) Something is fundamentally wrong here. Marcus On Sat, Nov 2, 2013 at 8:47 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > smalltalkhub is down: > http://www.downforeveryoneorjustme.com/smalltalkhub.com > > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 2, 2013

Re: [Pharo-dev] flatCollect:

by Sven Van Caekenberghe

On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the method proved to be very valuable in the context of Moose. > > However, the current Pharo implementation is less ideal: > > Collection>>flatCollect: aBlock > ^ Array streamContents: > [:stream | > self do: [:ea | stream nextPutAll: (aBlock value: ea)]] > > The Moose one is: > Collection>>flatCollect: aBlock > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock returns some kind > of collection for each element. Equivalent to the lisp's mapcan" > "original written by a. Kuhn and released under MIT" > > | stream | > self isEmpty ifTrue: [ ^ self copy ]. > stream := (self species new: 0) writeStream. > self do: [ :each | stream nextPutAll: (aBlock value: each) ]. > ^ stream contents > > The difference is in the type returned. The Pharo one always returns Array, while the Moose one returns a collection of the same species as the receiver. Sounds right, returning #species. > Does anyone have anything against the Moose implementation? > > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Nov. 2, 2013

Re: [Pharo-dev] Fuel: fix for Squeak trunk

by Nicolas Cellier

Thanks, and is there a public .mcz inbox, or does it require special rights? 2013/11/2 Max Leske <maxleske(a)gmail.com> > The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ > > On 01.11.2013, at 22:42, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > I have an easy fix for Fuel on Squeak trunk. > > It concerns the FuelCompatibility layer, so I hesitate to publish on > Pharo fogbugz... > > Is there a dedicated bug tracker? > > What is the preferred procedure? > > > > Nicolas > > >

Nov. 2, 2013

Re: [Pharo-dev] Update Fuel documentation

by Nicolas Cellier

No, it's not released. But we value continuous integration, and non regression on a set of supported package. And Fuel is one of the supported packages ( http://build.squeak.org/job/ExternalPackage-Fuel/) As I see it, Squeak trunk evolutions that break supported package deserve support from Squeak developers. So the idea would be to open a new compatibility version and grant some rights to interested developpers, at least in inbox. 2013/11/2 Max Leske <maxleske(a)gmail.com> > Thanks Nicolas. Weâll update the docs and fix the configuration. > > Has 4.5 been released? We had decided to wait with support for 4.5 until > it was released to prevent repetitive work. If 4.5 has indeed been released > weâll of course add support for 4.5. > > Cheers, > Max > > > On 01.11.2013, at 21:37, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > This page > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… obsolete information, at least for Squeak installation. > > This is because ConfigurationOfFuel-MaxLeske.178 still points to old > repository http://ss3.gemstone.com/ss/Fuel.html which has been drained... > ConfigurationOfFuel-MartinDias.209 should be a better starting point. > > In latest Squeak trunk there is another problem: lack of squeak4.5.x > support both in ConfigurationOfFuel and > MetacelloSqueakPlatform>>defaultPlatformAttributes. > But it's another problem, not related to documentation > > >

Nov. 2, 2013

Re: [Pharo-dev] how to set another inspector/explorer

by Tudor Girba

Exactly. That would be the solution I would favor as well. Doru On Sat, Nov 2, 2013 at 8:15 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 02 Nov 2013, at 07:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> > > It should not. I thought I removed it. ObjectExplorer should be removed > eventually (it is now only used for the PointerExplorer, which is a > subclass). > > > >> Anyway, I added #inspect: and #explore: to GTInspector class, and I > registered it as the #inspector. It seems fine, but the problem now is that > the default Spec-based debugger relies on a #inspectorSpec method in the > inspector class. > >> > > I think this can be easily fixed: somewhere in the Debugger, it calls > Smalltalk tools inspector where it should hard-code EyeInspector, as the > Debugger require this specific implementation. > Now finding that placeâ¦ I will check > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 2, 2013

Re: [Pharo-dev] how to set another inspector/explorer

by Tudor Girba

Hi Marcus, On Sat, Nov 2, 2013 at 7:17 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 01 Nov 2013, at 22:49, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > I am trying to set the GTInspector as the default explorer. > > > > However, I see that the inspector registration has changed. It seems to > me that registering to #objectExplorer has no effect. Instead, we are now > sending #inspect: and #explore to the #inspector: > > > > Object>>explore > > ^Smalltalk tools inspector explore: self > > > > I do not quite see the rationale behind the current design. > > With the new inspector, the inspector and explorer are the same tool. If > you open a normal inspector, you can even turn it into an explorer with a > keyboard shortcut. > Therefore it makes conceptually no sense to have a #objectExplorer tool. > There was a basicInspector in the tools, too, which is now gone. > > Explorers are just special inspectors, like the special inspectors for > CompiledMethod or Dictionary, just available for all classes. I agree that the explorer is like the inspector. But, if now they are the same, I do not see why we need to distinguish between them. I would leave only #inspect (no more #explore) around. However, a stripped down basic inspector can still be useful as a fallback solution in case the fancy one fails given that it relies on much more widgets that can cause exceptions. For example, try this in a fresh Pharo 3.0 image: Smalltalk tools explore You will get an exception. Having a basic inspector around is useful in this case. As it is now, the basic inspector is wrapped in a more complex widget which can induce errors in the future, and we get stuck. So, all in all, I argue that we need a basic inspector mapped on a more complicated keyboard shortcut. > Furthermore, Smalltalk tools still has an entry for #objectExplorer: > > (Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> > ObjectExplorer > > > It should not. I thought I removed it. ObjectExplorer should be removed > eventually (it is now only used for the PointerExplorer, which is a > subclass). Yes, I know. I was just pointing this out to show that I looked and that I was not sure of the current state. > > Anyway, I added #inspect: and #explore: to GTInspector class, and I > registered it as the #inspector. It seems fine, but the problem now is that > the default Spec-based debugger relies on a #inspectorSpec method in the > inspector class. > > > > This is highly problematic and I am stuck. I think we should not > introduce Spec-specific requirements at such a basic level. > > > > It should normally not âleakâ that the inspector is implemented with Spec, > you should be able to replace the inspector (via Smalltalk tools) with > another one. > So this should be checked and fixed. > Ok. > But it is clear that we can not have all the tools âin a crap version in > the kernelâ and âthat version that everyone usesâ. This Philosophy is > *wrong* just the same > for tools as it is for libraries. > +100. I completely agree that the core needs powerful tools. That is why I actually argued for Glamour in that base image a long time ago. I still want to make that argument, but this is a discussion for another time :). Doru > > Marcus > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 2, 2013

Re: [Pharo-dev] Fuel: fix for Squeak trunk

by Max Leske

The Fuel bug tracker is hosted by Google: https://code.google.com/p/fuel/ On 01.11.2013, at 22:42, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I have an easy fix for Fuel on Squeak trunk. > It concerns the FuelCompatibility layer, so I hesitate to publish on Pharo fogbugz... > Is there a dedicated bug tracker? > What is the preferred procedure? > > Nicolas

Nov. 2, 2013