- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About BitBlt current -> BitBlt (Fuel)

by Max Leske

Wowâ¦ Form is mindnumbingâ¦ On 30.10.2013, at 23:00, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > hehehe sorry, it was #hackBits: :) > > > On Wed, Oct 30, 2013 at 6:52 PM, Max Leske <maxleske(a)gmail.com> wrote: > Where did you find that method? I couldnât find any implementors or referencesâ¦ > > On 30.10.2013, at 21:42, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> BTW....it is time to move the hashBits: to a more general class....but the question is where? >> >> >> On Wed, Oct 30, 2013 at 6:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Fuel was using BitBlt current and I change that to BitBlt >> >> Stef >> >> On Oct 29, 2013, at 10:55 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> > Stef, what exactly is the influence on Fuel? I looked at the changes of your slice and couldnât find anythingâ¦ >> > >> > Max >> > >> > >> > On 25.10.2013, at 16:26, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > >> >> Hi >> >> >> >> I just pushed a change cleaning some strange usage. >> >> BitBlt was sometimes invoked via BitBlt current (which just returned the BitBlt class). >> >> Apparently in Squeak they removed it too. >> >> >> >> Now it touches Fuel so Fuel guys can you merge on your side too? >> >> >> >> https://pharo.fogbugz.com/f/cases/12009/BitBlt-current-BitBlt >> >> >> >> Stef >> > >> > >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

Nov. 1, 2013

Re: [Pharo-dev] Proposal for a Topic for the bachelor/master list [safe-image for teaching]

by Mariano Martinez Peck

Another similar project is a real working Image Locker for deploying... but not sure how much important it is... On Fri, Nov 1, 2013 at 5:10 PM, Max Leske <maxleske(a)gmail.com> wrote: > I think thatâs a good idea. Obviously thatâs something that none of us > developers want in the system but it would be good to have it from a > promotional point of view I guess. Could applications like Dr. Geo benefit > from such an environment? > > Max > > > On 01.11.2013, at 19:56, Gisela Decuzzi <giseladecuzzi(a)gmail.com> wrote: > > > Hi, I don't know where to send the proposal and I think that the list > would be a good place to talk about it. > > The main idea is to have a "safe" image, or a way to block or restrict > the modificable parts in the system, in order to avoid mistakes during the > learning. > > > > It could include protected packages, reduced browsers showing by default > user packages, configurable rules (by example: you can not create a class > with empty category, you can not create a class with the same name that a > known one). > > Maybe we can have a way to configure or to ask for permission to > modificate some parts of the system. > > Also, some filters during debugging, to avoid "protected" code. > > An easy way to obtain that image > > > > The idea is to reduce the common errors that we make when we start > programming also to help teachers. > > > > > > > > > -- Mariano http://marianopeck.wordpress.com

Nov. 1, 2013

Re: [Pharo-dev] Proposal for a Topic for the bachelor/master list [safe-image for teaching]

by Max Leske

I think thatâs a good idea. Obviously thatâs something that none of us developers want in the system but it would be good to have it from a promotional point of view I guess. Could applications like Dr. Geo benefit from such an environment? Max On 01.11.2013, at 19:56, Gisela Decuzzi <giseladecuzzi(a)gmail.com> wrote: > Hi, I don't know where to send the proposal and I think that the list would be a good place to talk about it. > The main idea is to have a "safe" image, or a way to block or restrict the modificable parts in the system, in order to avoid mistakes during the learning. > > It could include protected packages, reduced browsers showing by default user packages, configurable rules (by example: you can not create a class with empty category, you can not create a class with the same name that a known one). > Maybe we can have a way to configure or to ask for permission to modificate some parts of the system. > Also, some filters during debugging, to avoid "protected" code. > An easy way to obtain that image > > The idea is to reduce the common errors that we make when we start programming also to help teachers. > > >

Nov. 1, 2013

Proposal for a Topic for the bachelor/master list [safe-image for teaching]

by Gisela Decuzzi

Hi, I don't know where to send the proposal and I think that the list would be a good place to talk about it. The main idea is to have a "safe" image, or a way to block or restrict the modificable parts in the system, in order to avoid mistakes during the learning. It could include protected packages, reduced browsers showing by default user packages, configurable rules (by example: you can not create a class with empty category, you can not create a class with the same name that a known one). Maybe we can have a way to configure or to ask for permission to modificate some parts of the system. Also, some filters during debugging, to avoid "protected" code. An easy way to obtain that image The idea is to reduce the common errors that we make when we start programming also to help teachers.

Nov. 1, 2013

Re: [Pharo-dev] Using Gutenberg

by phil＠highoctane.be

Cool. I've tried to use the toolkit on Windows but it is a PITA. OSX Lion is fine. There are some socket errors and Worldstate messages when compiling a chapter: [PhilMac:/Volumes/Public/Dev/DevPharo/PharoForTheEnterprise-english philippeback$] ./compile.sh NativeBoost/NativeBoost.pier setsockopt: No buffer space available setsockopt: No buffer space available WorldState setsockopt: No buffer space available setsockopt: No buffer space available WorldState Compiling PDF... Compiling PDF... Output is fine. Lots of interesting material in the chapters. Artefact is of particular interest to me (creation of invoices). Now digesting the Pier syntax. Is there any Vim highlighting? I've downloaded the Wikipedia one, should be close to tweak in case there is no Vim plugin. Phil On Fri, Nov 1, 2013 at 7:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > done :) > > On Nov 1, 2013, at 2:48 PM, phil(a)highoctane.be wrote: > > philippeback > > >

Nov. 1, 2013

Re: [Pharo-dev] Using Gutenberg

by StÃ©phane Ducasse

done :) On Nov 1, 2013, at 2:48 PM, phil(a)highoctane.be wrote: > philippeback

Nov. 1, 2013

Re: [Pharo-dev] Debugging Morphs (was Re: Questions about Athens)

by kilon alios

Thanks guys, I already tried Stephane and now Camillo's suggestion with debug morph and works like a charm :) . Definetly makes my life a lot easier. btc self halt inserts a breakpoint to your code, so that execution stops there and debugger pops up. I find all this highly fascinating because its an area of coding that deeply interests me. Even when I don't code I love reading Pharo code, its so nice :) On Fri, Nov 1, 2013 at 7:13 PM, <btc(a)openinworld.com> wrote: > ** > Camillo Bruni wrote: > > On 2013-11-01, at 16:44, btc(a)openinworld.com wrote: > > > > kilon alios wrote: > > > About the problem to recreate it all it takes is a demo := AthensDemoMorph > new openInWorld . It opens the morph with the Athens grey box, I save the > image , close pharo, open pharo which reloads the image automagically and > BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph > since I cant find documentation to do things differently. > > So lets get to the questions > > 6) Also why there is a Red Box of Doom in the first place ? > > > > See #drawErrorOn: call from... > > Morph>>fullDrawOn: > self visible ifFalse: [^ self]. > (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas]. [ > "calls to each Morph's drawing stuff" > ] on: Error do: > [:err | > "Smalltalk at: #morphDebugOnce ifPresent: [ Smalltalk remove: #morphDebugOnce. self halt ]. > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: err freeze. > ^ self drawErrorOn: aCanvas ] > --------------- > In the past I have successfully debugged a morph by adding something like the commented line. Although I can't quite remember if 'self halt' is correct. Perhaps it should be 'err raise'. Perhaps others with more experience of the debugger internals can comment. > From a workspace just evaluate 'Smalltalk at: #morphDebugOnce put: #anything' before opening the morph. Or if the morph is already open and you have a reference theMorph, then you can try 'theMorph setProperty: #errorOnDraw toValue: false' to cause the bad morph code to run again. You can get a reference to an existing morph by enabling 'Create textual references to dropped morphs' from the window menu of a Workspace - then from the window menu select 'inspect variables' > > Now what would be really interesting is if in place of my commented line, the debugging context of the error was serialized using Fuel to a variable and then clicking on the red-square-of-death brought up a debugger on that. Something like this... > > Morph>>fullDrawOn: > self visible ifFalse: [^ self]. > (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas debugOn: (self property: #drawError) ]. [ > "calls to each Morph's drawing stuff" > ] on: Error do: > [:err | > self setProperty: #errorOnDraw toValue: true. > self setProperty: #drawError toValue: (Fuel serializedDebuggingContextOf: err. "***". > ^ self drawErrorOn: aCanvas ] > "*** Disclaimer: I haven't used Fuel yet, so I don't have the faintest idea what the proper method here should be." > > > You have in the halo menu an entry "debug drawing error" which does what you want. As you can see there is already the line: > > > self setProperty: #drawError toValue: err freeze. > > > which serializes the whole error (no need to use fuel as long as you stay in the image...). > > > Thats brilliant! I think thats new since last time I had to debug a > morph. I did see 'err freeze' in passing just earlier and wonder. > However the functionality is a bit hidden. To make it more obvious, > perhaps #drawErrorOn: could be modified as follows... > > self valueOfProperty: #drawError ifPresentDo: [ :error| | trace > stringBounds | > trace := String streamContents: [ :s| error signalerContext > shortDebugStackOn: s]. > trace := 'Use Halos>Debug>debug drawing error' , String cr , trace. > -------------------- > > btw kilon, you can experiment with that by adding a '1/0' to > EllipseMorph>>drawOn: > and evaluating (EllipseMorph new extent: 300@300) openInWorld. > > cheers -ben > > >

Nov. 1, 2013

Re: [Pharo-dev] Questions about Athens

by Igor Stasenko

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. 1, 2013

Re: [Pharo-dev] Debugging Morphs (was Re: Questions about Athens)

by btc＠openinworld.com

Nov. 1, 2013

[pharo-project/pharo-core]

by GitHub

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

Nov. 1, 2013