- Pharo-dev - lists.pharo.org

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

logCr and friends, why deprecation in 30?Â²

by phil＠highoctane.be

Hello I wanted to know why we deprecated logCr etc. TIA Phil

Oct. 12, 2014

Mysteries of the compiler

by Nicolai Hess

I tried to solve issues "13260 inspecting variables in the debugger fails in some cases" and "14058 Inconsistent information in debugger" and found some oddities in the way opal (compiler and the debuggermap) handles tempory variables. I am not sure if these are bugs. 1. order of temporaries: Evaluating this method |a b c| a:=1. b:=2. c:=3. thisContext tempNames logCr. ["in a block ! " thisContext tempNames logCr . a+b+c ] value. prints in the transcript #(#a #b #c) #(#a #b #c) - ok, both contexts, the method and block context, use the same ordering for the tempories writing on one variable in the block context require an indirection vector for the variable |a b c| a:=1. b:=2. c:=3. thisContext tempNames logCr. [b:=1. thisContext tempNames logCr. a+b+c ] value. here the variable b is written within the block context. This method prints #(#b #a #c) #(#a #c #b) - strange the variable order has changed and is not the same in both contexts. 2. OCOptimizedBlockScope Consider a whileTrue: call ["A-Block"] whileTrue:["B-Block"] or an ifTrue: ("some boolean value") ifTrue:["C-Block"] stepping into the blocks with the debugger and reading the values for a tempoariy variable shows that every block has an OCOpotimizedBlockScope as its scope. Are all 3 blocks the same kind of "optimized blocks"? because -> 3. Blocks within optimized blocks This method prints the number of tempories on the Transcript (the on:do: call is just a dummy for an "block within a block" but the important part is the usage of the three variables in the do-block) |a b c| a:=1. b:=2. c:=3. (c>0) ifTrue:[ [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. ]. thisContext method numTemps logCr. a The output on the transcript is "3" - ok This method is like the one above, but the nested block is in the receiver of the whileTrue:[] call (again, an optimized block, right?) |a b c| a:=1. b:=2. c:=3. [ [ a asString ] on:Error do:[:ex | a value:a value:b value:c]. c <0 ] whileTrue:[]. thisContext method numTemps logCr. a The output on the Transcript is "1" And it depends on the number of used variables in the do-Block The same method but with the do-Block do:[:ex | a value:a value:b] would print 2 as number of temporaries. nicolai

Oct. 12, 2014

Re: [Pharo-dev] OSProcess in 3.0

by David T. Lewis

On Fri, Oct 10, 2014 at 01:32:27PM -0400, David T. Lewis wrote: > > Le 10/10/2014 17:52, David T. Lewis a ?crit : > >>> 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > >>> > >>>> > >>>> Right. But please do test it in your applications to be sure, I really > >>>> only > >>>> did simple testing and I am sure there may still chances for problems > >>>> in > >>>> this area. > >>>> > >>> > >>> Hi Dave, > >>> > >>> Would it has a chance of slowing down things a lot? > >>> > >>> There is apparently something going very very slow compared to > >>> OSProcess > >>> 4.5.11 when used from GitFileTree. So slow that I killed the image > >>> building > >>> script before it was over. Reverting GitFileTree to 4.5.11 solved it. > >>> > >> > >> I don't this so, but I am not certain. The update for PipeableOSProcess > >> affects only the methods in PipeableOSProcess class>>command: and > >> closely > >> related methods. If GitFileTree is using that idiom, then it is > >> certainly > >> possible that I have introduced a bug that does not show up in my unit > >> tests. > > > > Typical code in GitFileTree is this: > > > > [ > > c := PipeableOSProcess command: ''. > > output := c output. > > ... > > ] ensure: [c closePipes] > > > > Maybe it's triggering something. > > > > Thierry > > > > Hmmm... I wonder if the #closePipes is causing a problem now. I don't know > if I ever tested to see if sending closePipes works after the pipes are > already closed, and my recent change closes the pipes after #output is > evaluated. I'll check it when I get home. > I tried this in both Squeak trunk and Pharo 3.0: (1 to: 100) collect: [:e | | c output | [c := PipeableOSProcess command: 'ls -lt'. output := c output. ] ensure: [c closePipes]. output ]. I get the expected results, and no open file handles left over. The #closePipes is no longer needed, so this can now be simplified as follows, which also leaves no open file handles: (1 to: 100) collect: [:e | (PipeableOSProcess command: 'ls -lt') output]. I am not sure what the issue is when used with GitFileTree, but it does not look like the change to PipeableOSProcess class>> command: is directly involved. But ... I'm probably missing something. If you are fairly sure the that problem is related to the the PipeableOSProcess change, then the only other thing I can think of right now is that there may be some other places in GitFileTree where PipeableOSProcess is being used in a different way, and maybe I caused a problem there due the the change in the #command: methods. But this a a complete guess, I really do not know. Dave

Oct. 11, 2014