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

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

by Torsten Bergmann

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] Artefact documentation is now in english

by phil＠highoctane.be

404 Not Found. Something wrong with the build. Phil On Sun, Oct 12, 2014 at 8:44 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks! > > Doru > > On Sun, Oct 12, 2014 at 7:36 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> I finished the translation of the chapter on Artefact the pdf generator >> library developed by O. Auverlot and G. Larcheveque. >> >> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ >> lastSuccessfulBuild/artifact/Artefact/Artefact.pillar.pdf >> >> Stef >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 12, 2014

Re: [Pharo-dev] Artefact documentation is now in english

by Tudor Girba

Thanks! Doru On Sun, Oct 12, 2014 at 7:36 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I finished the translation of the chapter on Artefact the pdf generator > library developed by O. Auverlot and G. Larcheveque. > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/ > lastSuccessfulBuild/artifact/Artefact/Artefact.pillar.pdf > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 12, 2014

Hapao crash and image recompile

by Alain Rastoul

Hi, After loading the last versions of S2py and Trachel (I had to do trachel manually, there was a missing method setupAdjust somewhere), I got a vm crash with Hapao>>Hapao @ class category and clicking ok for 'Roassal2-Core'. Looking at the crash dump, I saw 0x2477fc M CompiledMethod>literals 0x132d4f94: a(n) CompiledMethod 0x247814 M CompiledMethod>hasMethodSpyAsLiteral 0x132d4f94: a(n) CompiledMethod So I recompiled the whole image (Smalltalk image recompile) and everything is now ok :) I don't know if CompiledMethod modification involves transparent compilation of if some recompile is missing ? In case it could be useful to hapao dvelopers or to others (just in case). Alain

Oct. 12, 2014

Artefact documentation is now in english

by stepharo

Hi guys I finished the translation of the chapter on Artefact the pdf generator library developed by O. Auverlot and G. Larcheveque. https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… Stef

Oct. 12, 2014

OpenGL experts needed

by Nicolai Hess

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] logCr and friends, why deprecation in 30?Â²

by phil＠highoctane.be

BTW, what is the recommended way to use these days? I've got Toothpick in a corner, SystemLogger in another, and Beacon in a third. Net result: I write my own crap in a text logfile that I do log rotate. Phil On Sun, Oct 12, 2014 at 2:17 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Yes :) > > Doru > > On Sun, Oct 12, 2014 at 2:15 PM, stepharo <stepharo(a)free.fr> wrote: > >> In fact the concept of Cr is doomed. >> I will restart to work on SystemLogger and unify it with Beacon and we >> will just log objects. >> No Cr (text concept, string concept, ... perl.... grep.... >> arghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh) >> No select, detect just crappy text. >> >> Stef >> >> >> On 12 Oct 2014, at 13:17, phil(a)highoctane.be wrote: >>>> >>>> Hello >>>> >>>> I wanted to know why we deprecated logCr etc. >>>> >>>> It is not deprecatedâ¦ just in a category deprecated. >>> The methods even have senders. >>> >>> So: just work in progressâ¦ the idea is that this will be replaced >>> by a unified logging framework later. >>> >>> >>> Marcus >>> >>> >>> >>> >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 12, 2014

Re: [Pharo-dev] logCr and friends, why deprecation in 30?Â²

by Tudor Girba

Yes :) Doru On Sun, Oct 12, 2014 at 2:15 PM, stepharo <stepharo(a)free.fr> wrote: > In fact the concept of Cr is doomed. > I will restart to work on SystemLogger and unify it with Beacon and we > will just log objects. > No Cr (text concept, string concept, ... perl.... grep.... > arghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh) > No select, detect just crappy text. > > Stef > > > On 12 Oct 2014, at 13:17, phil(a)highoctane.be wrote: >>> >>> Hello >>> >>> I wanted to know why we deprecated logCr etc. >>> >>> It is not deprecatedâ¦ just in a category deprecated. >> The methods even have senders. >> >> So: just work in progressâ¦ the idea is that this will be replaced >> by a unified logging framework later. >> >> >> Marcus >> >> >> >> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 12, 2014

Re: [Pharo-dev] logCr and friends, why deprecation in 30?Â²

by stepharo

In fact the concept of Cr is doomed. I will restart to work on SystemLogger and unify it with Beacon and we will just log objects. No Cr (text concept, string concept, ... perl.... grep.... arghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh) No select, detect just crappy text. Stef >> On 12 Oct 2014, at 13:17, phil(a)highoctane.be wrote: >> >> Hello >> >> I wanted to know why we deprecated logCr etc. >> > It is not deprecatedâ¦ just in a category deprecated. > The methods even have senders. > > So: just work in progressâ¦ the idea is that this will be replaced > by a unified logging framework later. > > > Marcus > > > > >

Oct. 12, 2014

Re: [Pharo-dev] logCr and friends, why deprecation in 30?Â²

by Marcus Denker

> On 12 Oct 2014, at 13:17, phil(a)highoctane.be wrote: > > Hello > > I wanted to know why we deprecated logCr etc. > It is not deprecatedâ¦ just in a category deprecated. The methods even have senders. So: just work in progressâ¦ the idea is that this will be replaced by a unified logging framework later. Marcus

Oct. 12, 2014