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

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by Igor Stasenko

On 17 May 2013 10:21, kilon <thekilon(a)yahoo.co.uk> wrote: > Thank you all for your replies. I have used the solution I get new errors > now. Is there an example how to create a context with NBOpenGL because the > examples NBOpenGL is coming with are confusing at best ? > Pharo2.0 Latest update: #20590 (ConfigurationOfNBOpenGL project version: '2.0') load GLTTRenderingDemo new openInWorld (works well.. no errors whatsoever) See a superclass (GLViewportMorph). The context created using: display := NBGLDisplay extent: self extent. To get access to OpenGL API (a subinstance of NBOpenGL) just use: display gl. The actual class, responsible for creating OpenGL context is one of NBGLContextDriver subclasses, since it is highly platform-specific. driver := NBGLContextDriver createContext: 100@100. gl := driver gl. The display (NBGLDisplay) wraps around driver and has some initialization to set up defaults and resource management to make sure resources released when it garbage collected (the driver does not, and you must free it explicitly). To use GL API , just send #gl message to either display or driver: drawCube | gl | gl := display gl. gl translatef_x: -1.5 y: 0 z: -60. gl rotatef_angle: rotationAngle x: 0 y: 1 z: 0. gl begin: GL_TRIANGLES; ... end. Please note, that in NBGLContextDriver(s) i hardcoded many things like pixel format, and NBOffscreenDisplay rendering into offscreen buffer etc. That means, if you want to create own initializer, i would start from making own driver. Sorry but the stuff there is highly platform specific. Making a generic driver which would accept some initialization options (like pixel format, number of buffers etc) while freeing user from platform-specific horrors is something which could be done in future. But as i said before, the devil is always in details , and i would just leave this to application developer. P.S. If , by chance, you wanna make things less confusing and more obvious, feel free to contribute to the project, i can add you as developer. You can change/improve anything. I only asking to keep GLTTRenderingDemo working :) > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4688138.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 17, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by Chris Muller

On Fri, May 17, 2013 at 6:27 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I really enjoy smalltalk, every small thing that I discover every day. > > But there is one thing that really annoys me. The bold claim that small > functions do not need comments. > There is of course a level of truth that when a function/methods is well > formated and follows the common logic > rules of readable code a comment should not be needed for what it takes 10 > lines or less of code to explain. > > But then that is also an illusion. > > The problem is that the code never explains the why. And why can be very > important in understanding the code. You are right that comments should explain the "why" and not the "what". But not every single tiny little method needs to explain the "why" of its existence. Do you think hundreds and hundreds of #initialize methods need to explain themselves with a comment? I don't. > Also a big issue I have with smalltalk in general. All this spaggeti mess I > see unfold before my eyes in every library I see. > One method calling another method which calls (excuse me, I should have said > "sends a message") another and before > you know you forget where you started and where is the end. Its the > definition of Code Labyrinth. All this hectic browsing > around could have been avoided so easily with a single comment. Your frustration about use of the Composed Method pattern is due to a tool shortage, not a shortage of comments. Above, you're talking about getting "lost" as you trace through senders and implementors. When each sender/implementor either opens up a whole pane or, in some cases, a whole new window, then yes, it's very easy to get "lost" and forget where what you were doing due to following side-tracks. That's why I use Squeak's MessageTrace, it handles this better than anything else in any Smalltalk. It is a "lightweight" way, in terms of gestures and UI elements, to trace through code without getting lost. I wish Pharo would consider implementing a tool like this. > I would like to note here that I am also a big fan of small methods and that > my question is not related to whether methods > should be kept small and readable but whether comments are really needed for > those methods. Consulting Kent Beck's book, "Smalltalk Best Practice Patterns", page 40, on the "Method Comment" pattern. Kent suggests the percentage of methods that should need commenting is "between 0 and 1 percent." He continues about why on page 41: "Regardless of how well the system as a whole is put together, the big picture cannot easily be read method by method. There has to be another way of teaching the reader about the system as a whole." That's exactly what MessageTrace does. It shows the "big picture" of what's going on simply by arrowing up and down through the trace and reading the code. Comments are a human labor. They take time to write and time to read/ignore. Therefore, too many comments will actually *detract* from the quality and producitivity of a system if they're redundant, ambiguous, or sometimes even wrong, and making the code messy and hard to read. If, instead, we can design good-enough tools to _present_ the code model in a way that can be easily understood, then we don't need to labor over writing/reading comments except any more than 1% of the time. Cheers, Chris

May 17, 2013

Re: [Pharo-dev] [update 3.0] #30143

by Pavel Krivanek

Hi, it broke the Pharo Kernel 3.0 job: Error: MessageNotUnderstood: AnObsoleteCompilationContext class>>default 481 [...] in SmalltalkImage>>privShrinkingProcessWith: 2 BlockClosure>>cull: 3 BlockClosure>>cull:cull: 4 [...] in BlockClosure>>ifError: 5 BlockClosure>>cull: 6 [...] in MethodContext(ContextPart)>>handleSignal: 7 BlockClosure>>ensure: 8 MethodContext(ContextPart)>>handleSignal: 9 MessageNotUnderstood(Exception)>>signal 10 AnObsoleteCompilationContext class(Object)>>doesNotUnderstand: #default 11 Compiler>>compilationContext 12 RBMethodNode>>methodClass: 13 CompiledMethod>>parseTree 14 [...] in ASTCache>>at: 15 [...] in ASTCache(Dictionary)>>at:ifAbsentPut: 16 ASTCache(Dictionary)>>at:ifAbsent: 17 ASTCache(Dictionary)>>at:ifAbsentPut: 18 ASTCache>>at: 19 ASTCache class>>at: 20 CompiledMethod>>ast 21 CompiledMethod>>getSourceReplacingSelectorWith: 22 DictionaryTest class(Behavior)>>addTraitSelector:withMethod: 23 [...] in DictionaryTest class(Behavior)>>updateMethodDictionarySelector: 24 OrderedCollection>>do: 25 DictionaryTest class(Behavior)>>updateMethodDictionarySelector: 26 [...] in DictionaryTest class(Behavior)>>noteChangedSelectors: 27 IdentitySet(Set)>>do: 28 DictionaryTest class(Behavior)>>noteChangedSelectors: 29 DictionaryTest class(Behavior)>>applyChangesOfNewTraitCompositionReplacing: 30 DictionaryTest class(ClassDescription)>>applyChangesOfNewTraitCompositionReplacing: 31 DictionaryTest class(Class)>>applyChangesOfNewTraitCompositionReplacing: 32 DictionaryTest class(Behavior)>>setTraitComposition: 33 DictionaryTest class(Behavior)>>removeFromComposition: 34 [...] in Trait>>removeFromSystem: 35 IdentitySet(Set)>>do: 36 Trait>>removeFromSystem: 37 Trait>>removeFromSystem 38 [...] in [...] in SystemNavigation>>removeAllButPackages: 39 Array(Collection)>>ifEmpty: 40 [...] in SystemNavigation>>removeAllButPackages: 41 SortedCollection(OrderedCollection)>>do: 42 SystemNavigation>>removeAllButPackages: 43 [...] in SmalltalkImage>>privShrinkingProcessWith: 44 BlockClosure>>on:do: 45 BlockClosure>>ifError: 46 SmalltalkImage>>privShrinkingProcessWith: 47 [...] in SmalltalkImage>>shrinkToKernelWith: 48 [...] in BlockClosure>>newProcess So I'll try to put Opal into the Kernel :-) -- Pavel On Fri, May 17, 2013 at 4:11 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 30143 > ----- > > 10615 RBMethodNode classBinding: move it to compilationContext > https://pharo.fogbugz.com/f/cases/10615/ > > ... and update Opal to the latest version > > > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.154.diff > > >

May 17, 2013

Stop saving the image at the end of an 'eval' script!

by Damien Cassou

Hi, If you have scripts you call with the command line argument 'eval' like this: ./pharo eval '1+2. Smalltalk snapshot: true andQuit: true' you will get into problems in Pharo 2.0 (e.g., a debugger with 'stdout is closed' message). Pharo 3.0 does not have this problem. The correct way to do that in Pharo 2.0 is: ./pharo eval --save '1+2' which is non-arguably much cleaner :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 17, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by phil＠highoctane.be

A simple: "Provides the ability to...." "Provides support for..." "Enables to ..." already goes a long way. Phil 2013/5/17 Igor Stasenko <siguctua(a)gmail.com> > On 17 May 2013 13:46, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > I agree with you. > > > > Methods should be commented!!!! > > > indeed.. i like reading nice comments.., much less than writing them, > however :) > > nice point that comments must focus on answering "why" but not "how" > > > > > On May 17, 2013, at 1:27 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> > wrote: > > > > I really enjoy smalltalk, every small thing that I discover every day. > > > > But there is one thing that really annoys me. The bold claim that small > > functions do not need comments. > > There is of course a level of truth that when a function/methods is well > > formated and follows the common logic > > rules of readable code a comment should not be needed for what it takes > 10 > > lines or less of code to explain. > > > > But then that is also an illusion. > > > > The problem is that the code never explains the why. And why can be very > > important in understanding the code. > > Also a big issue I have with smalltalk in general. All this spaggeti > mess I > > see unfold before my eyes in every library I see. > > One method calling another method which calls (excuse me, I should have > said > > "sends a message") another and before > > you know you forget where you started and where is the end. Its the > > definition of Code Labyrinth. All this hectic browsing > > around could have been avoided so easily with a single comment. > > > > Its those moments you beg for a comment or some documentation. > > > > So my message to this list is to express my discomfort on this and ask > > > > Is it me or is this a really bad code practice afterall ? > > > > I am new to smalltalk so maybe I miss something or maybe things get > easier > > in the future with more experience. > > But something it tells me inside that I will never get used to this , > maybe > > I will learn to tolerate it , but its so far away from > > my way of thinking I dont think it has much chance into integrating in my > > brain. > > > > The thing is that I am quite the opposite , I am a comment and > documentation > > freak. You may think I do it just to be > > awared the oscar of amazing readable coding but nothing can be further > from > > the truth. I may be coding for 25 years now > > but it was never something serious , I am no pro and certainly not a > serious > > coder. I just like to mess around with code, thats all. > > > > For me its a matter of survivability , if I dont comment or document I > will > > quickly forget why I code these things anyway. > > Its so easy for me to forget and be confused and I find in this case > > smalltalk code is not as forging to coders like me. > > > > So I would like to hear you thoughts on this as much more experience > > smalltalk coders than me. > > > > I would like to note here that I am also a big fan of small methods and > that > > my question is not related to whether methods > > should be kept small and readable but whether comments are really needed > for > > those methods. > > > > > > > > -- > Best regards, > Igor Stasenko. > >

May 17, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by Igor Stasenko

On 17 May 2013 13:46, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I agree with you. > > Methods should be commented!!!! > indeed.. i like reading nice comments.., much less than writing them, however :) nice point that comments must focus on answering "why" but not "how" > > On May 17, 2013, at 1:27 PM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > I really enjoy smalltalk, every small thing that I discover every day. > > But there is one thing that really annoys me. The bold claim that small > functions do not need comments. > There is of course a level of truth that when a function/methods is well > formated and follows the common logic > rules of readable code a comment should not be needed for what it takes 10 > lines or less of code to explain. > > But then that is also an illusion. > > The problem is that the code never explains the why. And why can be very > important in understanding the code. > Also a big issue I have with smalltalk in general. All this spaggeti mess I > see unfold before my eyes in every library I see. > One method calling another method which calls (excuse me, I should have said > "sends a message") another and before > you know you forget where you started and where is the end. Its the > definition of Code Labyrinth. All this hectic browsing > around could have been avoided so easily with a single comment. > > Its those moments you beg for a comment or some documentation. > > So my message to this list is to express my discomfort on this and ask > > Is it me or is this a really bad code practice afterall ? > > I am new to smalltalk so maybe I miss something or maybe things get easier > in the future with more experience. > But something it tells me inside that I will never get used to this , maybe > I will learn to tolerate it , but its so far away from > my way of thinking I dont think it has much chance into integrating in my > brain. > > The thing is that I am quite the opposite , I am a comment and documentation > freak. You may think I do it just to be > awared the oscar of amazing readable coding but nothing can be further from > the truth. I may be coding for 25 years now > but it was never something serious , I am no pro and certainly not a serious > coder. I just like to mess around with code, thats all. > > For me its a matter of survivability , if I dont comment or document I will > quickly forget why I code these things anyway. > Its so easy for me to forget and be confused and I find in this case > smalltalk code is not as forging to coders like me. > > So I would like to hear you thoughts on this as much more experience > smalltalk coders than me. > > I would like to note here that I am also a big fan of small methods and that > my question is not related to whether methods > should be kept small and readable but whether comments are really needed for > those methods. > > -- Best regards, Igor Stasenko.

May 17, 2013

[update 3.0] #30143

by Marcus Denker

30143 ----- 10615 RBMethodNode classBinding: move it to compilationContext https://pharo.fogbugz.com/f/cases/10615/ ... and update Opal to the latest version Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Tests-MarcusDenk… http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/AST-Core-MarcusDenker.154.diff

May 17, 2013

Re: [Pharo-dev] AsmJit-Core not in Pharo30 repository

by Pavel Krivanek

of course SmartSuggestions and NodeNavigation are dependent on this packages :-) On Fri, May 17, 2013 at 3:56 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > Please, can you somehow place the packages there? I cannot test morphic > reloading without it. > Some package is dependent on ConfigurationOfNodeNavigation. > > -- Pavel > > > On Fri, May 17, 2013 at 3:53 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> >> On May 17, 2013, at 3:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >> ...and some other AsmJit packages, ConfigurationOfNodeNavigation >> and ConfigurationOfSmartSuggestions >> >> >> Yes, we need to improve the setupâ¦ right now we commit to pharo and then >> merge later with upstream. >> This is not good. >> >> -- Pavel >> >> On Fri, May 17, 2013 at 3:30 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com >> > wrote: >> >>> Hi, >>> >>> the package AsmJit-Core has in Smalltalkhub Pharo30 repository no >>> version. >>> >>> Cheers, >>> -- Pavel >>> >> >> >> >

May 17, 2013

Re: [Pharo-dev] AsmJit-Core not in Pharo30 repository

by stephane ducasse

marcus you will explain that to me so that I understand. Stef On May 17, 2013, at 3:53 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 17, 2013, at 3:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> ...and some other AsmJit packages, ConfigurationOfNodeNavigation and ConfigurationOfSmartSuggestions >> > > Yes, we need to improve the setupâ¦ right now we commit to pharo and then merge later with upstream. > This is not good. > >> -- Pavel >> >> On Fri, May 17, 2013 at 3:30 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> the package AsmJit-Core has in Smalltalkhub Pharo30 repository no version. >> >> Cheers, >> -- Pavel >> >

May 17, 2013

Re: [Pharo-dev] AsmJit-Core not in Pharo30 repository

by Pavel Krivanek

Please, can you somehow place the packages there? I cannot test morphic reloading without it. Some package is dependent on ConfigurationOfNodeNavigation. -- Pavel On Fri, May 17, 2013 at 3:53 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 17, 2013, at 3:35 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > ...and some other AsmJit packages, ConfigurationOfNodeNavigation > and ConfigurationOfSmartSuggestions > > > Yes, we need to improve the setupâ¦ right now we commit to pharo and then > merge later with upstream. > This is not good. > > -- Pavel > > On Fri, May 17, 2013 at 3:30 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > >> Hi, >> >> the package AsmJit-Core has in Smalltalkhub Pharo30 repository no version. >> >> Cheers, >> -- Pavel >> > > >

May 17, 2013