January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] latest build yields stack trace running #cleanUpForProduction

by StÃ©phane Ducasse

Hi Yanni open a bug entry. We got some strange behavior with becomeForward: and set rehash and I wonder if this is not related. stef On Jan 17, 2012, at 10:03 PM, Yanni Chiu wrote: > Using Pharo 1.4 (#220), I end up in: > ByteSymbol(Object)>>doesNotUnderstand: #run:with:in: > > which was called from: > (MCPackage named: self theScriptLoaderPackageName) unload. > > First I thought it was because I had OSProcess loaded when I ran cleanUpForProduction, and it stopped in an OSProcess class. > > Without OSProcess, the I got a slightly different problem: the doesNotUnderstand of #run:with:in: is due to something in #cleanUpForRelease. Trying to debug it, new debuggers pop up, and then the emergency evaluator. > > I have Seaside30/Magritte/Pier loaded, so I can try without those too. But, it used to work with all these things loaded. > > -- > Yanni > >

Jan. 17, 2012

Re: [Pharo-project] Speeding up Finder string search

by Stefan Marr

And here we go: On 17 Jan 2012, at 19:37, Stefan Marr wrote: > After fixing that, I get these numbers: > #(102851 10781 10798 9511 10335 9883) > Not really impressive. > > I did not immediately see how to avoid the compression. > The image size goes currently up by ca. 50%, from 22MB to 31MB. #(76700 1787 1793 1768 1741 1748) That is space for performance: image size is at 39MB. Not that my version with an extra dictionary is still faster by about 20% (1.4s vs. 1.7s) since it avoids the decoding from the compiled method. Is there any general use for such an embedding, beside making the finder usable? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 17, 2012

Re: [Pharo-project] Exception logging

by Nicolas Cellier

2012/1/17 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Silly question, but Â what happens to your newProcess if you don't resume it? > > Â [Beeper primitiveBeep] newProcess. > > won't beep... But: > > Â [Beeper primitiveBeep] newProcess resume. > > will... > > If you did resume then > - What is OCClosureCompiler? > - Does it generate an exception? > - Did you try with a regular Compiler? > > With a regular Compiler I clearly here the buzzer. hem... hear > > Nicolas > > 2012/1/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Thanks guys >> now what is really strange to me is that whe the code does not contain error to make it compile I have to wrap it with on:do: >> Any idea? >> >> >>> and if I wrap the execution with a on: error do: >>> I get >>> Â Â Â Start33 in the file >>> >>> >>> OCClosureCompiler >>> >>> >>> if I remove the on:do: >>> I do not get anything no beep. >> >>

Jan. 17, 2012

Re: [Pharo-project] [Pharo-users] First steps making OB work in 1.4

by StÃ©phane Ducasse

On Jan 17, 2012, at 5:19 PM, Guillermo Polito wrote: > Hi! > > I've been working the last days in making OB work in pharo 1.4. I updated several deprecations like method reference and stuff and discovered some bugs that I've already published in: > > http://code.google.com/p/pharo/issues/detail?id=5189&q=milestone%3D1.4&cols… > http://code.google.com/p/pharo/issues/detail?id=5183&q=milestone%3D1.4&cols… > > I've already proposed some fixes for them, but if anyone can have a look too I'll feel better :). > Those fixes are needed in order to load OB. Meanwhile, you can also have some patches from the cs and fileout I attach. > > What's working now? OB + OCompletion + Shout + Sunit integration. > > So, It's everything but Refactoring browser, which is a little more difficult since there is another RB version loaded in the image :P. I will unload it as I mentioned in the other emails. > > To load it (after integrating the patches): > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOmniBrowser'; > load. > > (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Core Tests' 'OCompletion Tests' ) , #( 'Core' 'OB-SUnitIntegration' 'OB-Shout' 'OCForOB'). > > Cheers, > Guille > <pluggable list morph fix.1.cs><Slider-setValue.st>

Jan. 17, 2012

Re: [Pharo-project] Exception logging

by Nicolas Cellier

Silly question, but what happens to your newProcess if you don't resume it? [Beeper primitiveBeep] newProcess. won't beep... But: [Beeper primitiveBeep] newProcess resume. will... If you did resume then - What is OCClosureCompiler? - Does it generate an exception? - Did you try with a regular Compiler? With a regular Compiler I clearly here the buzzer. Nicolas 2012/1/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Thanks guys > now what is really strange to me is that whe the code does not contain error to make it compile I have to wrap it with on:do: > Any idea? > > >> and if I wrap the execution with a on: error do: >> I get >> Â Â Â Start33 in the file >> >> >> OCClosureCompiler >> >> >> if I remove the on:do: >> I do not get anything no beep. > >

Jan. 17, 2012

[Pharo-project] latest build yields stack trace running #cleanUpForProduction

by Yanni Chiu

Using Pharo 1.4 (#220), I end up in: ByteSymbol(Object)>>doesNotUnderstand: #run:with:in: which was called from: (MCPackage named: self theScriptLoaderPackageName) unload. First I thought it was because I had OSProcess loaded when I ran cleanUpForProduction, and it stopped in an OSProcess class. Without OSProcess, the I got a slightly different problem: the doesNotUnderstand of #run:with:in: is due to something in #cleanUpForRelease. Trying to debug it, new debuggers pop up, and then the emergency evaluator. I have Seaside30/Magritte/Pier loaded, so I can try without those too. But, it used to work with all these things loaded. -- Yanni

Jan. 17, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Frank Shearar

On 17 January 2012 20:16, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > Am 17.01.2012 um 13:26 schrieb Frank Shearar: > >> On 17 January 2012 03:20, blake <dsblakewatson(a)gmail.com> wrote: >>> On Mon, Jan 16, 2012 at 2:43 PM, Frank Shearar <frank.shearar(a)gmail.com> >>> wrote: >>> >>> >>> Frank, >>> >>> I agree with what you said EXCEPT that I don't see the NIH mentality in >>> Smalltalk. What I do see, and have seen a lot of over the years, is people >>> coming in and banging on Smalltalk's differences without taking the time to >>> learn the whys and wherefores. I don't think it's knee-jerk defense so much >>> as a creeping sense that the person complaining maybe isn't in the best >>> position to do so. (And I say this as someone who's been on several sides of >>> the argument.) >> >> I'm aware of the reasons why the NIH arises, and I'm sure that's part >> of why the reaction arises in many other communities. I reserve the >> right to say "ahem, take the time to actually read what the person's >> asking for, because they might actually have good ideas". >> >> And, in particular, Gerry raises concerns _this very list_ has raised. >> Living permanently in the image is _bad_, which is why we're moving to >> Metacello for everything so we can _construct_ an image. Look at > There is a big difference between rescuing artifacts outside the image for distribution, reuse and storage > and working outside the image. I would like to be able to remotely debug Smalltalk but not for the price of giving up what we already have. > For me there is a big advantage to have the "living objects world". There might be alternatives to the image > concept in order to have it. But Eclipse, NetBeans, Emacs, vi and Visual Studio don't provide anything better. > Each these IDE's are in itself bigger and more complex than Pharo. > These IDE's provide tools to deal with big muds of dead code - quite the opposite of a "living objects world". Emacs + SLIME = image-based, interactive development. As image-based as you'd like, at least. Eclipse + Cusp = image-based development: you're connecting to a running Common Lisp image, which you can snapshot and restore any time you like (just like choosing to work in a built image or in a persistent one). IDE and "living world" are orthogonal concerns. frank frank

Jan. 17, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Janko MivÅ¡ek

.. also SSD won't necessary use Flash technology in the future, there are already alternatives close to production level, which solve exactly that write problem. In any case, in few years we will have such a hierarchical persistent memory from slow SSD up to fastest CPU caches available. S, Michael Haupt piÅ¡e: > ... BTW that's what I meant with optimisations. > > Am 14.01.2012 um 19:34 schrieb Guido Stepken <gstepken(a)googlemail.com > <mailto:gstepken@googlemail.com>>: > >> Read about "wear leveling"? So, no problem with write cycles. For >> example yffs2 filesystem gives you a tremendous gain in lifetime of >> your USB flash storage. >> >> regards, Guido Stepken >> >> Am 14.01.2012 15:56 schrieb "Michael Haupt" <mhaupt(a)gmail.com >> <mailto:mhaupt@gmail.com>>: >> >> Hi, >> >> 2012/1/14 Janko MivÅ¡ek <janko.mivsek(a)eranova.si >> <mailto:janko.mivsek@eranova.si>>: >> > Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of >> > caching from SSD up to CPU? Automatic, supported by OS or even >> hardware, >> > as CPU caches are? Then image wont be needed to be read to RAM and >> > snapshoted back to disk, it can be run directly from disk. >> >> SSDs are Flash memory. The number of write cycles is limited before >> the memory starts to fail. Smalltalk frequently performs GC, which >> involves moving objects, i.e., writing. Writing is also much slower >> than reading, and AFAIK possible only block-wise (with a block being >> significantly larger than your average object). Flash file systems >> apply optimisations to distribute writing evenly, avoiding excessive >> writing in some places and consequent earlier failure. >> >> Best, >> >> Michael >> -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Jan. 17, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Andreas Wacknitz

Am 17.01.2012 um 13:26 schrieb Frank Shearar: > On 17 January 2012 03:20, blake <dsblakewatson(a)gmail.com> wrote: >> On Mon, Jan 16, 2012 at 2:43 PM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >> >> >> Frank, >> >> I agree with what you said EXCEPT that I don't see the NIH mentality in >> Smalltalk. What I do see, and have seen a lot of over the years, is people >> coming in and banging on Smalltalk's differences without taking the time to >> learn the whys and wherefores. I don't think it's knee-jerk defense so much >> as a creeping sense that the person complaining maybe isn't in the best >> position to do so. (And I say this as someone who's been on several sides of >> the argument.) > > I'm aware of the reasons why the NIH arises, and I'm sure that's part > of why the reaction arises in many other communities. I reserve the > right to say "ahem, take the time to actually read what the person's > asking for, because they might actually have good ideas". > > And, in particular, Gerry raises concerns _this very list_ has raised. > Living permanently in the image is _bad_, which is why we're moving to > Metacello for everything so we can _construct_ an image. Look at There is a big difference between rescuing artifacts outside the image for distribution, reuse and storage and working outside the image. I would like to be able to remotely debug Smalltalk but not for the price of giving up what we already have. For me there is a big advantage to have the "living objects world". There might be alternatives to the image concept in order to have it. But Eclipse, NetBeans, Emacs, vi and Visual Studio don't provide anything better. Each these IDE's are in itself bigger and more complex than Pharo. These IDE's provide tools to deal with big muds of dead code - quite the opposite of a "living objects world". With each new release the get a little bit nearer to what our "living object world" gives us but with the big price tag of overwhelming complexity and never being able to really overtake. So yes, we should be open minded to enhance our world. Eg. Pharo lacks some standard widgets like a grid. The whole GUI framework should be modernized. Polymorph is a step in the right direction in my opinion. Our versioning systems should be able to deal with artifacts (documents, drawings and so on) from the outside world. But unless the versioning system of the outside world will provide what we need there is no real advance in using them for Smalltalk. There are already alternatives to the standard Smalltalk systems. GNU smalltalk left behind the image and is using a standard GUI framework. You can edit the code in your preferred editor. F-Script is an example for embedding the Smalltalk syntax in the Mac world. The Cocoa framework is directly accessible. There are other Smalltalks directly embedded into Java, DOT.NET and even Javascript. So a lot of people already had the idea to move outside the traditional Smalltalk world and did that in several projects. But to my knowledge they didn't get much attention. No revolution happened. Andreas

Jan. 17, 2012

Re: [Pharo-project] Saga of trying to integrate IDE with OpenGL continuesRe: [squeak-dev] Re:NativeBoost and NBOpenGL on Mac?

by Lawson English

That is really Igor's job, not mine. I'm just throwing together stuff using the original Croquet OpenGL calls and making videos of what I'm doing. L. On 1/17/12 10:31 AM, Alexandre Bergel wrote: > Keep going. I would love to have opengl well integrated. > > Alexandre > > > > On 16 Jan 2012, at 23:44, Lawson English wrote: > >> The latest video in the saga: http://www.youtube.com/watch?v=TsJmBwi9lDY >> >> BTW, the video I mentioned a day or so ago now has 90 views, in only 3 days. >> >> People who want to promote squeak/pharo/seaside/etc to the world at large should take note. >> >> L. >> >> >> >> >> On 1/14/12 12:20 PM, Igor Stasenko wrote: >>> [...] >>>>> well, one of the ideas is to use fallback display in case of openGL >>>>> error(s). >>>>> And render not to GL context but to bitmap. Then you can actually use >>>>> debugger to debug GL calls step by step >>>>> without interfering with GL stack/state. >>>>> Another approach would be to create a separate GL context and use it >>>>> for debugger. But then you need to keep an eye >>>>> for switching active contexts at right moment. >>>>> >>>>>> L. >>>>>> >>> >>

Jan. 17, 2012