November 2014 - Pharo-dev - lists.pharo.org

Merge conflict for "META Case: restructure Tests and test packages"

by Nicolai Hess

for example : https://pharo.fogbugz.com/default.asp?14433 I don't why there is a merge conflict, maybe it is how the slice is created. I think the restructuring (moving all classes from XXXTest to XXX-Tests) would work if we delete the empty XXXTests package before creating the slice. nicolai

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Eliot Miranda

On Tue, Nov 18, 2014 at 1:12 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > See > https://news.ycombinator.com/item?id=8625280 > > [ (1 to: 100000000) sum ] timeToRun > > Here we get out of the SmallInteger range... > > Apart FFI'ing the thing, do we have other options? > We're planning to have a Spur 64-bit system next year. Sista will inline the block in sum. But it's hardly representative. It's a constant. If performance is important, put it in a class variable. What do you really want to go fast? -- best, Eliot

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Andreas Wacknitz

Am 18.11.14 22:12, schrieb phil(a)highoctane.be: > See > https://news.ycombinator.com/item?id=8625280 > > [ (1 to: 100000000) sum ] timeToRun > > Here we get out of the SmallInteger range... > > Apart FFI'ing the thing, do we have other options? > > Phil Choose a better algorithm: [100000000 * 10000001 / 2] timeToRun should beat yours by several orders of magnitude. Andreas

Nov. 18, 2014

Re: [Pharo-dev] Can we make this fast ?

by Alexandre Bergel

Yes, you can use OpenCL. There is a bridge Pharo<â> OpenCL made by Ronie, available on smalltalkhub. Ronie has also been working on a DSL to easily write OpenCL applications. This is cool stuff! Have a look! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 18, 2014, at 6:12 PM, phil(a)highoctane.be wrote: > > See > https://news.ycombinator.com/item?id=8625280 <https://news.ycombinator.com/item?id=8625280> > > [ (1 to: 100000000) sum ] timeToRun > > Here we get out of the SmallInteger range... > > Apart FFI'ing the thing, do we have other options? > > Phil

Nov. 18, 2014

Can we make this fast ?

by phil＠highoctane.be

See https://news.ycombinator.com/item?id=8625280 [ (1 to: 100000000) sum ] timeToRun Here we get out of the SmallInteger range... Apart FFI'ing the thing, do we have other options? Phil

Nov. 18, 2014

Pharo contributions server gone

by Torsten Bergmann

https://ci.inria.fr/pharo-contribution Restart?

Nov. 18, 2014

Pharo contribution Jenkins offline

by Yuriy Tymchuk

Can someone (re)boot it? Thanks Uko

Nov. 18, 2014

Re: [Pharo-dev] GLViewportMorph>>#layoutInBounds:

by Igor Stasenko

To elaborate.. i made GLViewportMorph to serve as an example how to set things up and glue opengl context with morphic. For anyone who knows things a bit, how opengl works, it becomes obvious, that doing things the way GLViewportMorph does is not the best way.. you cannot achieve good framerate with it and so it is not a serious piece of software, but a toy. That's why extending its functionality to make things more robust and versatile or safer never was my objective, because it is inherently impossible with such setup. Making things properly would take much more time which i didn't had. Perhaps one day if i will have project that using opengl, i will take an effort and make things more robust, or perhaps someone else will do it. -- Best regards, Igor Stasenko.

Nov. 18, 2014

Re: [Pharo-dev] GLViewportMorph>>#layoutInBounds:

by Yuriy Tymchuk

Makes sense. Thanks > On 18 Nov 2014, at 19:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 18 November 2014 16:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > >> On 18 Nov 2014, at 13:03, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: >> >> >> >> On 18 November 2014 06:58, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> Yes, true, but if I want height to be flexible (maybe Iâm not good in spec) and have a row that has fixed height and then this morph which adjusts. It works well after it opens, but when it opens you get errorâ¦ Does it make sense to add to layoutInBounds: check if the bounds are visible, otherwise there is no reason to layout anything? >> >> >> it makes sense to not create opengl object(s) with null dimensions, to avoid errors. > > As you are one of the authors of NBOpenGL, can you please add this feature? > > > Nope. > NBOpenGL cares about only one feature: it lets you use OpenGL library the way you want. > It is bindings to external library. The correct use of the library is responsibility of its users, not NBOpenGL. > You discovered a single problem of incorrect use of opengl library.. but imagine how many other you can discover when you will start using things seriously.. do you think we shall modify bindings each time someone incorrectly use them? > NBOpenGL cannot ensure that application developers using things properly. It is impossible and waste of effort. > > > Uko > >> >>> On 18 Nov 2014, at 00:23, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> >>> 2014-11-17 22:52 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>> Hi, >>> >>> can someone advise me how to deal with one issue. >>> >>> I put Roassal3D morph is a spec composite model, and when I open the window I get 'Frame buffer is incomplete: GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENTâ error because GLViewportMorph>>#layoutInBounds: bounds attribute has a zero coordinate. Should there be a guard in the method of GLViewportMorph, or I should do something in Spec? >>> >>> Uko >>> >>> Works for me, as long as I add a height (or width) in the spec layout: >>> >>> ^ SpecLayout composed >>> newColumn: [ :column | >>> column >>> add: #view3d height:80 ]; >>> yourself >>> >>> (view3d is a Roassal3DModel >>> view3d := self instantiate: Roassal3DModel. >>> view3d view: >>> (R3View new >>> add: R3CubeShape element; >>> addInteraction: R3MKControl). >>> >>> ) >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > > -- > Best regards, > Igor Stasenko.

Nov. 18, 2014

Re: [Pharo-dev] GLViewportMorph>>#layoutInBounds:

by Igor Stasenko

On 18 November 2014 16:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 18 Nov 2014, at 13:03, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 18 November 2014 06:58, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Yes, true, but if I want height to be flexible (maybe Iâm not good in >> spec) and have a row that has fixed height and then this morph which >> adjusts. It works well after it opens, but when it opens you get errorâ¦ >> Does it make sense to add to layoutInBounds: check if the bounds are >> visible, otherwise there is no reason to layout anything? >> >> > it makes sense to not create opengl object(s) with null dimensions, to > avoid errors. > > > As you are one of the authors of NBOpenGL, can you please add this feature? > > Nope. NBOpenGL cares about only one feature: it lets you use OpenGL library the way you want. It is bindings to external library. The correct use of the library is responsibility of its users, not NBOpenGL. You discovered a single problem of incorrect use of opengl library.. but imagine how many other you can discover when you will start using things seriously.. do you think we shall modify bindings each time someone incorrectly use them? NBOpenGL cannot ensure that application developers using things properly. It is impossible and waste of effort. Uko > > > >> On 18 Nov 2014, at 00:23, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> 2014-11-17 22:52 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> >>> Hi, >>> >>> can someone advise me how to deal with one issue. >>> >>> I put Roassal3D morph is a spec composite model, and when I open the >>> window I get 'Frame buffer is incomplete: >>> GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENTâ error because >>> GLViewportMorph>>#layoutInBounds: bounds attribute has a zero coordinate. >>> Should there be a guard in the method of GLViewportMorph, or I should do >>> something in Spec? >>> >>> Uko >>> >> >> Works for me, as long as I add a height (or width) in the spec layout: >> >> ^ SpecLayout composed >> newColumn: [ :column | >> column >> add: #view3d height:80 ]; >> yourself >> >> (view3d is a Roassal3DModel >> view3d := self instantiate: Roassal3DModel. >> view3d view: >> (R3View new >> add: R3CubeShape element; >> addInteraction: R3MKControl). >> >> ) >> >> >> > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Nov. 18, 2014