- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Kernel Discussion

by Esteban Lorenzano

well... I said the same when I was applying those changes, he :) I already made a note in my TODO list to refactor that as soon as possible too :) Esteban On May 25, 2013, at 12:55 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I've seen a lot of progress for the Pharo Kernel by Pavel recently and I > really appreciate his work. But I have some questions I think we should discuss. > > There have been quite a few changes to make code work in the Kernel and to > reduce dependencies between packages. But I really have the impression that > many of these changes are of bad quality :/. > > I do not want to offend people, but this is fairly important if we want to > have a nice code base. > > Example: > ======== > UnixResolver >> nbGetEnv: str > #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. > ^ nil > > The goal of this code is to conditionally do something in the main image but > continue to work in the kernel. > > Observations: > ============= > - #asClassIfPresent: and Co are bad > - Why do we clutter the main image if the kernel should change? > - Can't we solve these things by having proper other objects? > - Is the UnixResolver really needed in the Kernel? > > I worked with Esteban last week on a similar case in the CommandLineHandler and we ended up introducing a minimal superclass. I guess this goes much in the direction of having proper NullObjects. > > I really think we should not add these little nasty changes, but rather introduce proper > new classes that can be unloaded if needed. > > What do you think?

May 25, 2013

are there benchmarks like deltablue and richards for Pharo?

by Esteban Lorenzano

Hi, I wonder if there are benchmarks around. Also I wonder if there would be useful :) For "marketing" purposes I think yes: if we can put in the web page that we are running those benchmarks, it is cool for "seriousness" (that, of course, assuming the results will not be terribly bad :P) Esteban

May 25, 2013

Kernel Discussion

by Camillo Bruni

I've seen a lot of progress for the Pharo Kernel by Pavel recently and I really appreciate his work. But I have some questions I think we should discuss. There have been quite a few changes to make code work in the Kernel and to reduce dependencies between packages. But I really have the impression that many of these changes are of bad quality :/. I do not want to offend people, but this is fairly important if we want to have a nice code base. Example: ======== UnixResolver >> nbGetEnv: str #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. ^ nil The goal of this code is to conditionally do something in the main image but continue to work in the kernel. Observations: ============= - #asClassIfPresent: and Co are bad - Why do we clutter the main image if the kernel should change? - Can't we solve these things by having proper other objects? - Is the UnixResolver really needed in the Kernel? I worked with Esteban last week on a similar case in the CommandLineHandler and we ended up introducing a minimal superclass. I guess this goes much in the direction of having proper NullObjects. I really think we should not add these little nasty changes, but rather introduce proper new classes that can be unloaded if needed. What do you think?

May 25, 2013

Re: [Pharo-dev] TxText new version 0.8

by Camillo Bruni

>>> so that means nobody *actually* loads code without tests? :D (evil laugh). > > But i do not argue about what is the be best deployment scenario. > > I am arguing about leaving developers to choose: > - if (s)he wants to deploy with tests or not, it should be up to him. it's also up to him to - write configurations - write tests - write documentation and examples - commit code to a repository - create jenkins jobs you see, there are many things that one can avoid to do in a project, yet it is a common standard to do ALL of these tasks for a project. Yet you have your liberty to ignore these things. It is about the good path and how you push people towards it. If you do not provide the tools for it we will be stuck in stone age forever. It has never been the liberty of ignoring things that brought a project forward, but the tools that open new possibilities. How does an ideal project look for you?

May 25, 2013

[update 3.0] #30166

by Marcus Denker

30166 ----- 10674 Failing Regressiontest: MethodPragmaTest>>#testCompileInvalid https://pharo.fogbugz.com/f/cases/10674 10736 Fix shortcut for smart suggestions in mac https://pharo.fogbugz.com/f/cases/10736 10726 Enhance methods comments in FileSystem https://pharo.fogbugz.com/f/cases/10726 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/SmartSuggestions-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/KernelTests-MarcusDenker.518.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Tests-Core-MarcusD… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Memory-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.…

May 25, 2013

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

by Igor Stasenko

I added you as contributor to project. Feel free to contribute! :) I would love to play more with OpenGL, but i am swamped with other stuff. -- Best regards, Igor Stasenko.

May 25, 2013

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

by Igor Stasenko

On 22 May 2013 20:00, kilon <thekilon(a)yahoo.co.uk> wrote: > Hey Igor , yes I would love to contrinbute to NBOpenGL for a very long time. > I could at least fix those small errors like the one I reported and add > documentation to methods and > especially classes. > > I am using pharo 3.0 and GLTTRenderingDemo does not work. I get an error. > > Apparently it cannot find ShortPointArray which is initialised inside > TTCountourConstruction>>asCompressedPoints > Okay, seems like this class got removed. (i think i remember seeing issue abound it)... I already saved some classes which was thrown out of Pharo image into separate package (like code to read and decypher .tff files). But changes keep going.. (what a surprise ;) and so require energy and time to keep things up to date. > I remember having same issues with pharo 2.0 too. > > I am also confused how to use NBGLCurveRenderer. > you don't. i made this class purely for my demo purposes. the code there is far-far from general use. :) > Thank you for your detailed explanation I have tried GLViewportMorphic I see > no errors , so its should work fine. > > I am new to opengl myself , and smalltalk and nativeboost so I try to > understand as much I can before doing actual coding and I feel I am at that > stage that I can do and I would love to contribute my work back to pharo > because I plan to implement at least a basic 3d engine and very basic > MoprhicGL GUI. > so, if you able to instantiate GLViewport and open it in window, try to render something (simple triangles etc..) and see if you get anything. > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689207.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 25, 2013

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

by Igor Stasenko

On 22 May 2013 20:11, kilon <thekilon(a)yahoo.co.uk> wrote: > I am looking at NBGLContextDriver and NBGLDisplay and I see none of that hard > coded stuff. > Look more carefully: there's a code to manage viewport and setting up buffers and other things, like blend more etc in those classes. It is not platform-specific (because it uses purely only opengl api), but it doesn't makes it less hardcoded. > I assume you mean the platform specific packages like NBMacGLContextDriver > ,NBGLXContextDriver etc. where I see alot of platform specific code inside > the methods of those classes . > Yes, it has to be platform-specific. But do not confuse "hardcoded" stuff with "platform-specific" code. Ideally, there should be no hardcoded one, but it is hard to achieve (for the reasons i mentioned before, and one of them is platform-specificness, of course). > -- > View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689211.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 25, 2013

Re: [Pharo-dev] Fwd: [vwnc] [ANN] SmalltalkFit

by Igor Stasenko

Looks like an interesting approach to write tests. I should take a look. Because indeed, for Athens rendering.. comparing rendered bits is a bit silly, knowing that rendering quality may differ depending on backend. >From other side, you need to test that it is "works" in some way. On 24 May 2013 19:17, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > > > Begin forwarded message: > > From: Randy Coulman <rcoulman(a)gmail.com> > Subject: [vwnc] [ANN] SmalltalkFit > Date: May 24, 2013 5:18:26 PM GMT+02:00 > To: VW NC <vwnc(a)cs.uiuc.edu> > > I have just released the latest version of SmalltalkFit, an implementation > of Ward Cunningham's Framework for Integrated Tests, > Fitnesse, and Rick Mugridge's FitLibrary. > > Fit is a tool for writing acceptance tests (integration > tests/examples/executable specifications/whatever you want to call them). > Fitnesse is a wiki wrapper around Fit, and FitLibrary adds additional ways > of writing the tests. > > This version of SmalltalkFit includes the equivalent features of Fit Java > 1.1, Fitnesse 20121220, and FitLibrary 2.0. It does not (yet) include a port > of Fitnesse Slim. > > SmalltalkFit is available in the Cincom Public Store Repository. A snapshot > of the current version is also on GitHub. The Readme file on GitHub includes > high-level documentation if you'd like more information before diving in. > > The full release announcement is on my blog, Courageous Software. > > Thanks, > Randy > > -- > Randy Coulman > Email: rcoulman(a)gmail.com > Home: http://randycoulman.com > Twitter: @randycoulman GitHub: randycoulman > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- Best regards, Igor Stasenko.

May 25, 2013

Spec and list item size

by StÃ©phane Ducasse

Hi How can I specify that the size of a liste element is two lines? Stef

May 25, 2013