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

Re: [Pharo-dev] [SO] GT error in fresh 3.0

by Nicolai Hess

This can happen if he (or maybe this happens automatically for some images) exported settings from other images (moose/pharo4). look in %APPDATA%\pharo for any exported settings. 2014-10-13 11:11 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > This is odd since 3.0 shouldnât even include GT. > > > http://stackoverflow.com/questions/26332910/downloaded-pharo-3-0-fails-on-s… >

Oct. 13, 2014

Smalltalk Devroom at FOSDEM 2015: Call for Participation

by Stephan Eggermont

Call for Participation in the Smalltalk Devroom at FOSDEM 2015. http://www.fosdem.org, please forward " A devroom for the Pharo, Squeak, Amber, GST, EtoilÃ©, Seaside, Moose Smalltalk projects & Objective Smalltalk and Newspeak as derived languages. Smalltalk environments offer a very high development productivity, unmatched by their successors. Come do some pair programming with us and experience yourself the advantages of a real OO environment" The meetup will take place Sunday, February 1, 2015, room S.H.2214. This room has 100 seats, a VGA video projector and wireless internet. Presentations will be video recorded (CC BY). Proposals on content and format are welcome. HOW TO SUBMIT: All submissions are made in the Pentabarf event planning tool at https://penta.fosdem.org/submission/FOSDEM15 When submitting your talk in Pentabarf, make sure to select the 'Smalltalk devroom' as the 'Track'. If you already have an account there, please reuse it. QUESTIONS & VOLUNTEERS Any questions, and video volunteers, please mail to stephan[@]stack[dot]nl with [FOSDEM] in the subject. I will send out updates on a regular basis to the lists and anyone stating his interest. PLANNED SCHEDULE: Sessions of 30/60 minutes (-5 min setup), last session a two hour hands-on introduction to smalltalk. First session or lunch session can be show-us-your-project, lightning talks. The desired time slot is meant to help you prevent conflicts with other dev rooms in which you might have a talk or your travel arrangements. There are alternative, non smalltalk-specific tracks available: lightning talk and the main track Please submit before December 1, 23:00 GMT+1. Devroom related URLs: http://www.pharo.org http://www.squeak.org/ http://etoileos.com/ http://www.seaside.st/ http://smalltalk.gnu.org/ http://www.moosetechnology.org http://amber-lang.net http://newspeaklanguage.org/ http://http://objective.st http://www.esug.org FOSDEM is the Free and Open source Software Developers' European Meeting, a free and non-commercial two-day weekend event that offers open source contributors a place to meet, share ideas and collaborate.

Oct. 13, 2014

[SO] GT error in fresh 3.0

by Max Leske

This is odd since 3.0 shouldnât even include GT. http://stackoverflow.com/questions/26332910/downloaded-pharo-3-0-fails-on-s…

Oct. 13, 2014

Re: [Pharo-dev] Athens: issue with clipping and/or path drawing

by Yahoo-Plantec

Thanks Nicolai! it works with the last vm. Thanks a lot. Cheers Alain On 13 oct. 2014, at 09:05, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-10-13 8:53 GMT+02:00 Alain Plantec <alain.plantec(a)yahoo.com>: > Dear All, > The border is not well rendered when a submorph is partly > outside the bounds of the AthensWrapMorph. > The AthensWrapMorph is set to clip its submorphs. > See the two small screenshots with an ellipse morph. > Is it a known issue or am I doing something wrong ? > > | a e | > a := AthensWrapMorph new clipSubmorphs: true. > e := EllipseMorph new. > e position: 100@100. > a addMorph: e. > a openInWorld > > Thanks > Alain > > <Screen Shot 2014-10-13 at 08.42.18.png><Screen Shot 2014-10-13 at 08.42.33.png> > > > There was an issue on windows and mac os. The vm didn't use the latest > cairo lib: > 13364 > Mac OS X and Windows VM with newer Cairo > > Does it work for you with the latest pharo-vm? > > Nicolai > >

Oct. 13, 2014

Re: [Pharo-dev] Athens: issue with clipping and/or path drawing

by Nicolai Hess

2014-10-13 8:53 GMT+02:00 Alain Plantec <alain.plantec(a)yahoo.com>: > Dear All, > The border is not well rendered when a submorph is partly > outside the bounds of the AthensWrapMorph. > The AthensWrapMorph is set to clip its submorphs. > See the two small screenshots with an ellipse morph. > Is it a known issue or am I doing something wrong ? > > | a e | > a := AthensWrapMorph new clipSubmorphs: true. > e := EllipseMorph new. > e position: 100@100. > a addMorph: e. > a openInWorld > > Thanks > Alain > > There was an issue on windows and mac os. The vm didn't use the latest cairo lib: 13364 <https://pharo.fogbugz.com/default.asp?13364> Mac OS X and Windows VM with newer Cairo Does it work for you with the latest pharo-vm? Nicolai

Oct. 13, 2014

Athens: issue with clipping and/or path drawing

by Alain Plantec

Dear All, The border is not well rendered when a submorph is partly outside the bounds of the AthensWrapMorph. The AthensWrapMorph is set to clip its submorphs. See the two small screenshots with an ellipse morph. Is it a known issue or am I doing something wrong ? | a e | a := AthensWrapMorph new clipSubmorphs: true. e := EllipseMorph new. e position: 100@100. a addMorph: e. a openInWorld Thanks Alain

Oct. 13, 2014

Re: [Pharo-dev] Working configuration of OS and Graphiccard for Woden

by Nicolai Hess

2014-09-28 23:58 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > Is Woden supposed to work on windows? > I tried > Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: > 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) > loadBleedingEdge > on windows but it failed (some NB error). > I just want to know if anyone tried woden on Windows already. > I tried this on linux too, but it fails. > (But I wasn't able to run Roassal3D or NBOpenGL on my > linux box so I hadn't high expectations, > but at least on my windows box I could get NBOpenGL > working) > > > Nicolai > solved: It was a driver issue. With the latest ATI driver on windows woden examples are working.

Oct. 12, 2014

Re: [Pharo-dev] OpenGL experts needed

by Nicolai Hess

Thank you Ronie, 2014-10-12 21:47 GMT+02:00 Ronie Salgado <roniesalg(a)gmail.com>: > Hello, > > You should start trying to use Woden and Woden-Roassal. Everything of > Roassal 3D will be moved to Woden. > http://smalltalkhub.com/#!/~ronsaldo/Woden . To install it you only have > to run this script: > > Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: > 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) > loadBleedingEdgeIn Woden I have many bugs to fix, which I havent because I > have been busy the last month making the new FFI. > > I have still problems with NBOpenGL with an ATI Radeon HD 4250 >> Graphic card > > What graphic driver do you have? AMD stopped providing support to the > graphics cards older than the HD 5xxx, If i remember it correctly. I guess > that you are using the open source drivers. > I feel so stupid. On windows I was pretty sure it is the most recent one. (I checked the driver settings and on "update" it shows "Already up to date"-message). Now I manually downloaded the latest driver from ATI and ... ... It works now! (and the woden examples are working too). Nicolai > > Greetings, > Ronie > > 2014-10-12 14:03 GMT-03:00 Nicolai Hess <nicolaihess(a)web.de>: > > like described here >> http://forum.world.st/Roassal-3D-empty-windows-td4749249.html >> and here >> http://forum.world.st/NBOpenGL-on-Windows-td4749309.html >> >> I have still problems with NBOpenGL with an ATI Radeon HD 4250 >> Graphic card >> >> No way to get it to work on linux (dont' know why). >> >> On windows I had the issue that the rendering only happens in >> the upper window corner (rendering only happens within the >> initial morph/framebuffer bounds). >> >> I finally solved this issue by reattaching the renderbuffers after every >> resize. >> ( in NBGLFrameBuffer>>#resize: >> I call >> self bind >> and >> for all attachments I call #resize: and #attachTo:as: >> (I had to change the attachments set to store the attachment type as >> well)) >> >> Now my question is, is it a bug in ATIs opengl implementation >> Or are all other users just lucky, that it works for them? >> Or it is just uncommon to work with framebuffer objects this way? >> Don't know if my solution just works now, but is otherwise wrong >> or resuls in leaks or other side effects. >> >> (Actually there are tons of examples and tutorials online about >> framebuffer objects and render-to-texture, but none I found covers the >> case >> of a changed framebuffer size) >> >> Anyone has some expert knowledge on using framebuffers for >> render-to-texture >> where this target texture may change its size? >> Anyone working with NBOpenGL and hasn't this issue can tell me >> which Grahic card he uses? >> Or anyone knows something about bugs in ATIs OpenGL driver which >> may be responsible for this behavior? >> (I read about another bug with render-to-texture but that one only >> happened for NVIDIA cards) >> >> thanks in advance >> Nicolai >> >> (btw in NBGLCurveRenderer there is still a problem with >> NBGLFragmentProgramARB vs NBGLFragmentProgram. >> All this with Pharo3.0 Latest update: #30858 latest NBOpenGL image >> from Pharo Contribution Jenkins) >> >> >> >> >

Oct. 12, 2014

Re: [Pharo-dev] Serious problem with ConfigurationOfBootstrap - Error: Apparent loop in import expansion

by phil＠highoctane.be

It turned out that the problem appeared randomly on various configurations and the cause is possibly a low memory condition. Also possible is an instable smalltalkhub. The problems were blocking us for a while with no clear cause. That is quite annoying. Phil Le 12 oct. 2014 21:35, "Torsten Bergmann" <astares(a)gmx.de> a Ã©crit : > > Hi Phil, > > nothing I can reproduce here. I tried with the latest/fresh > Pharo 3.0 (build 30858) image. No problem to load from script or config > browser. > Also CI is green. > > Are you already using Pharo 4.0? Then it might be related that > the prerequisite Seaside version may be not yet be ready/supported > for Pharo 4.0. > https://ci.inria.fr/pharo-contribution/job/Pharo4Seaside/ > > Bye > T. > > > > > >

Oct. 12, 2014

Re: [Pharo-dev] OpenGL experts needed

by Ronie Salgado

Hello, You should start trying to use Woden and Woden-Roassal. Everything of Roassal 3D will be moved to Woden. http://smalltalkhub.com/#!/~ronsaldo/Woden . To install it you only have to run this script: Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge In Woden I have many bugs to fix, which I havent because I have been busy the last month making the new FFI. I have still problems with NBOpenGL with an ATI Radeon HD 4250 > Graphic card What graphic driver do you have? AMD stopped providing support to the graphics cards older than the HD 5xxx, If i remember it correctly. I guess that you are using the open source drivers. Greetings, Ronie 2014-10-12 14:03 GMT-03:00 Nicolai Hess <nicolaihess(a)web.de>: > like described here > http://forum.world.st/Roassal-3D-empty-windows-td4749249.html > and here > http://forum.world.st/NBOpenGL-on-Windows-td4749309.html > > I have still problems with NBOpenGL with an ATI Radeon HD 4250 > Graphic card > > No way to get it to work on linux (dont' know why). > > On windows I had the issue that the rendering only happens in > the upper window corner (rendering only happens within the > initial morph/framebuffer bounds). > > I finally solved this issue by reattaching the renderbuffers after every > resize. > ( in NBGLFrameBuffer>>#resize: > I call > self bind > and > for all attachments I call #resize: and #attachTo:as: > (I had to change the attachments set to store the attachment type as well)) > > Now my question is, is it a bug in ATIs opengl implementation > Or are all other users just lucky, that it works for them? > Or it is just uncommon to work with framebuffer objects this way? > Don't know if my solution just works now, but is otherwise wrong > or resuls in leaks or other side effects. > > (Actually there are tons of examples and tutorials online about > framebuffer objects and render-to-texture, but none I found covers the case > of a changed framebuffer size) > > Anyone has some expert knowledge on using framebuffers for > render-to-texture > where this target texture may change its size? > Anyone working with NBOpenGL and hasn't this issue can tell me > which Grahic card he uses? > Or anyone knows something about bugs in ATIs OpenGL driver which > may be responsible for this behavior? > (I read about another bug with render-to-texture but that one only > happened for NVIDIA cards) > > thanks in advance > Nicolai > > (btw in NBGLCurveRenderer there is still a problem with > NBGLFragmentProgramARB vs NBGLFragmentProgram. > All this with Pharo3.0 Latest update: #30858 latest NBOpenGL image > from Pharo Contribution Jenkins) > > > >

Oct. 12, 2014