- Pharo-users - lists.pharo.org

Re: [Pharo-users] Woden not loading anymore

by Stephan Eggermont

On 18-06-15 10:12, Lusa Nicolas wrote: > it was a while that I wasn't updating the woden version that I am using in my project, so today I thought to give it a try and see if there was something new. > And now I am not able to load woden anymore, what I get is the following error message: > Error: Name not found: WithOpenGLAndExamples ConfigurationOfWoden depends on ConfigurationOfOSWindow. It depends on version #development. Development of OSWindow happens on Pharo 5. There is no specific (older) version for Pharo 4. I prefer software to work on both the current release and the current bleeding edge, but that isn't always possible. The ConfigurationOfOSWindow preloaded in 50120 is not the latest version. I was able to load (ConfigurationOfWoden project version: #development) load: #thales after loading ConfigurationOfOSWindow-jb.10 from Pharo/OSWindow I tried loading #thales because it doesn't load Roassal2, which has interesting problems in its configuration (see Moose mailing list) Running the Woden tests didn't seem to work in a reasonable time frame, but I could just do a WDFPSSimpleExample open Most others work, until they need some picture files. This all on a Ubuntu 15.04 Linux machine. Stephan

June 19, 2015

Re: [Pharo-users] World lastKeystroke and openInWorld: aPasteUpMorph

by Markus Schlager

On Tue, 16 Jun 2015, Hilaire wrote: > Off topic, but I am curious as a teacher: how old the pupils you are > teaching to? I use Etoys or Scratch in grade 7 (age about 12 years) and Smalltalk in grade 10 (age about 15/16 years). They are attending regular "Informatik"-courses at Gymnasium, supposed to learn object-oriented modeling and programming. Markus

June 18, 2015

Corrupted image after refactoring in class hierarchy

by Hilaire

Hello, I am facing again this situation, with Pharo3, when the image becomes corrupted (crash at instanciation of a refactored class in a hierarchy). This time I have a log, it looks like a problem in ClassModification. Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 18, 2015

Re: [Pharo-users] What would be the first code snippet you would show

by Dmitri Zagidulin

Stef: +1 about using somethign with ZnClient. Manipulating web pages (getting data, or filling out forms) is something all students can understand and get excited about (versus some of the other traditional code snippets in books). Sven: Wow, nice link! Those are excellent snippets. On Wed, Jun 17, 2015 at 4:13 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Here are some more > > https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0 > > Maybe for teaching, the example should somehow be familiar, recognisable. > On the other hand, that might be confusing and lead to too many > comparisons. > > > On 17 Jun 2015, at 21:53, stepharo <stepharo(a)free.fr> wrote: > > > > Hi > > > > For the mooc I have a lecture called Pharo Syntax in a nutshell and I > would love to get a couple of simple examples > > that show the syntax but are not totally boring. > > > > I thought about something like > > > > > > ZnClient new > > url: 'http://localhost:8080/books/1'; > > formAt: 'author' put: 'SquareBracketAssociates'; > > formAt: 'title' put: 'Pharo For The Enterprise'; > > put > > > > > > > > Stef > > > > >

June 18, 2015

Athens and radial gradient

by Matthieu Lacaton

Hello, I wanted to use Athens API to define a radial gradient and I saw that the class RadialGradientPaint only had one radius as instance variable and it seemed to me it was passed as the end radius while the start radius was set to 0. Does it mean that if I want to define a start radius different from 0 I need to call the backend directly ? Thanks, Matthieu

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Stephan Eggermont

On 18-06-15 13:35, Damien Cassou wrote: > > Stephan Eggermont <stephan(a)stack.nl> writes: > >> ApplicationTreeModelAdapter>>childrenFor: anObject >> ^mapping at: anObject >> >> ApplicationTreeModelAdapter>>childrenFor: anObject >> ^(mapping at: anObject class) value: anObject > > the same method with 2 different behaviors. > Hmm, still not awake yet? Note to self: do not program in a text editor. childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mapping at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) value: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent | ^OrderedCollection new] at: self DCDiagram class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent | OrderedCollection withAll: parent nodes] and you could of course remove the ApplicationTreeModelAdapter sharedInstance register: part and use a pragma Stephan

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Damien Cassou

Stephan Eggermont <stephan(a)stack.nl> writes: > ApplicationTreeModelAdapter>>childrenFor: anObject > ^mapping at: anObject > > ApplicationTreeModelAdapter>>childrenFor: anObject > ^(mapping at: anObject class) value: anObject the same method with 2 different behaviors. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Stephan Eggermont

Wake up before posting childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mapping at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) value: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent| ^OrderedCollection new] at: self

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Stephan Eggermont

childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mappaing at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) with: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent| ^OrderedCollection new] at: self

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Christophe Demarey

Why not try to use TreeNodeModel to define different kind of nodes? On each node you can redefine the way to get children, the icon, etc. Then you give these nodes as the tree roots. Le 18 juin 2015 Ã 10:10, Peter UhnÃ¡k a Ã©crit : > > > I don't fully understand the TreeModel example, what would your tool do with all the men/displayBlock/childrenBlock ... - methods? > > > Ah, I should've explained what TreeModel is; it is a Spec UI widget to display tree-like structures: > > > â > > So the way this works is that I give the TreeModel some root object (DCFsm) and then blocks that describes some behavior. > So in childrenBlock: [ :parent | ... ] the block is expected to return child elements for the parent. > In displayBlock: you pass a block that returns the label that you will see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ] > iconBlock: returns the icon for the object and so on and so forth. > > So the way I have implemented it right now is something like > > ~~~~~~~~~~~~~~~~~ > childrenFor: anObject > | col name | > name := anObject class asString asSymbol. > col := OrderedCollection new. > name = #DMMindMap > ifTrue: [ ^ col ]. > (anObject isKindOf: DCDiagram) > ifTrue: [ col addAll: anObject elements ]. > (anObject isKindOf: DCNamedElement) > ifTrue: [ > name = #BormParticipant > ifTrue: [ col addAll: anObject nodes ]. > name = #BormActivity | (name = #BormState) > ifTrue: [ col addAll: anObject outgoing ]. > name = #BormActivity > ifTrue: [ col addAll: anObject sent ]. > name = #BormCommunication > ifTrue: [ col addAll: anObject dataFlows ]. > name = #BormCommunication > ifTrue: [ > anObject hasConstraint > ifTrue: [ col add: anObject constraint ] ]. > name = #BormTransition > ifTrue: [ > anObject hasConstraint > ifTrue: [ col add: anObject constraint ] ] ]. > ^ col > ~~~~~~~~~~~~~~~~~ > > Which is unreadable, unmaintainable and nonextensible. All the #Borm* symbols actually refer to classes of a completely independent package and repository which doesn't even need to be loaded in the system. > > I think what Peter means is: the object oriented way to handle different types is by dispatching on each type (~ double dispatch, ~ visiting). You could need this for different aspects of your application. In the end, the same core mechanism will be implemented multiple times. Sadly, minor semantics/structural differences will make it hard to abstract this out. > > Yes, double-dispatch seems like the apt solution, however it would lead to NxM number of classes (as mentioned before). But the more I think about it the more I feel that I will not get any better than that. > > Peter

June 18, 2015