- Pharo-dev - lists.pharo.org

StartupPreference bug?

by StÃ©phane Ducasse

| items | items := OrderedCollection new. items add: (StartupAction name: 'Basic settings' code: [ Author fullName: 'MarianoMartinezPeck'. Debugger alwaysOpenFullDebugger: true.]). StartupLoader default addAtStartupInPreferenceVersionFolder: items named: 'basicSettings.st'. generates more basicSettings.st StartupLoader default executeAtomicItems: { StartupAction name: 'Basic settings' code: [...]. }. Stef

June 23, 2013

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

by kilon

thank you , it works now. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694696.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 23, 2013

Re: [Pharo-dev] Object >> #is:

by Nicolas Cellier

Except that if an object both is: this and is: that, from two different packages, this will lead to an override. 2013/6/23 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > can we remove that, or is this still in use? > > Hmm, no senders, no implementors, but the idea is not bad: it could > replace a lot of methods. And it bears the signature of some illustrious > hackersâ¦ > > Sven >

June 23, 2013

Re: [Pharo-dev] Object >> #is:

by Sven Van Caekenberghe

On 23 Jun 2013, at 18:14, Camillo Bruni <camillobruni(a)gmail.com> wrote: > can we remove that, or is this still in use? Hmm, no senders, no implementors, but the idea is not bad: it could replace a lot of methods. And it bears the signature of some illustrious hackersâ¦ Sven

June 23, 2013

Object >> #is:

by Camillo Bruni

can we remove that, or is this still in use?

June 23, 2013

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

by Marcus Denker

On Jun 23, 2013, at 5:51 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > yeah and I read about that in PBE and of course I forgot about it. That is > why we need the mailing lists. > > Ok that solved the problem partially it does not complain about > strVertexShader but it still complains about strFragmentShader . I use this > code. > > shaderList := {strVertexShader strFragmentShader}. > > Any idea what may still be wrong ? > There needs to be a dot: shaderList := {strVertexShader . strFragmentShader}. (I guess I forgot to put it in my example) > "strFragmentShader appears to be unused in this method. Ok to remove it ?"

June 23, 2013

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

by kilon

yeah and I read about that in PBE and of course I forgot about it. That is why we need the mailing lists. Ok that solved the problem partially it does not complain about strVertexShader but it still complains about strFragmentShader . I use this code. shaderList := {strVertexShader strFragmentShader}. Any idea what may still be wrong ? "strFragmentShader appears to be unused in this method. Ok to remove it ?" -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694685.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 23, 2013

[update 3.0] #30216

by Marcus Denker

30216 ----- 10995 remove #printWithClosureAnalysisOn: https://pharo.fogbugz.com/f/cases/10995 10985 StepList full of useless morphs https://pharo.fogbugz.com/f/cases/10985 10892 flatCollect added to pharo https://pharo.fogbugz.com/f/cases/10892 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.516.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.17.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1493.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.491.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Collections-Abstract-MarcusDe…

June 23, 2013

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

by Marcus Denker

On Jun 23, 2013, at 4:52 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > next question . > > I have this method. > > initializeProgram > "create each shader and program" > > | shaderList strVertexShader strFragmentShader | > > strVertexShader := self createShader: GL_VERTEX_SHADER string: ( self > vertexShader ). > strFragmentShader := self createShader: GL_FRAGMENT_SHADER string: (self > fragmentShader) . > shaderList := #( strVertexShader strFragmentShader ). > self createProgram: shaderList . > shaderList do: [ :each | gl deleteShader: each ]. > > > Each time I try to accept the code it complains that strVertexShader and > strFragmentShader are unused and ask for removing them . Why ? > > Is this an IDE bug ? Its clear from the code that I use those two local > variables to pass them to the array shaderList. Am I missing something here > ? Yes: shaderList := #( strVertexShader strFragmentShader ). here the Array you create is a so called literal Array. It can not contain variables, only literals. The compiler sees is as #(#strVertexShader #strFragmentShader). What you need instead is a compile time evaluated Array: shaderList := {strVertexShader strFragmentShader}. Marcus

June 23, 2013

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

by StÃ©phane Ducasse

+1 On Jun 23, 2013, at 12:31 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-23, at 12:29, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> On Fri, Jun 21, 2013 at 6:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> (pass 6, last?) >> >> >> looks like it was the last one. I would like to congratulate and thank >> Sebastian and you. This change was not easy at all and the results are >> important. For example, now, the RGClass class, the Trait class and >> the Class class will be truly polymorphic. > > > good job guys! this one was bugging me for a while, but I never had the courage > to deal with it ;)

June 23, 2013