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

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

by StÃ©phane Ducasse

hi guys this was a lively discussion. Now it you want to improve our system, you can do it!. Did you see my easy to guess wonderful subliminal message? We have no problem of vision just lack of manpower. I always wanted the best of both worlds: a scriptable system with a syntax for VI lovers with a image when you want it based on a core that can bootstrap itself and load package at lighting speed. BTW I'm writing a document explaining the goals, process and current efforts in Pharo so that people can understand the big picture and join and help Stef

Jan. 18, 2012

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

by Yanni Chiu

On 17/01/12 11:14 PM, Yanni Chiu wrote: > On 17/01/12 5:15 PM, Mariano Martinez Peck wrote: >> >> can you reproduce the problem with that ? > > Nope, the code worked in both the new and old images. Here's how I've reproduced the problem. Happens about half the time out of a handful of times - using a new image (that was never saved). 1. Get a new Pharo1.4 download 2. Open browser on implementers of #cleanUp: 3. Find the HashedCollection class>>#cleanUp: method in the browser 4. Select "self compactAll" and doIt I've gotten the attached stacktrace twice, and it worked without problem another two times - even executed the code: Smalltalk allClassesAndTraitsDo: [...] to try to detect the problem, but when it worked, it worked.

Jan. 18, 2012

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

by Friedrich Dominicus

Lawson English <lenglish5(a)cox.net> writes: > 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. Just so much I'd tried to get this all running under Pharo. I guess 32-bit Pharo on 64-bit Debian is not a good base for running OpenGL stuff ;-( -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Jan. 18, 2012

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

by Friedrich Dominicus

Jimmie Houchin <jlhouchin(a)gmail.com> writes: > I am all for improving our editing experience. But I want it in my > image and not in Emacs/vi. I would rather see our world improved than > to see it require an external editor which sees code as text, not > objects, where different external editors have differing features. Well I suggest then to start with adding an Editor which deserves that name. By all means the editors in any Smalltalk are poor. And now that you mention Emacs. There is nothing comparable to this Editor for Text editing in any Smalltalk world-wide. So yes you an live within the live "objects!" but you have to leave them whenever you want to write something more but 5 lines of code. > > And yes, I am thoroughly pro Pharo. Do I believe there are > deficiencies. Yes. I just don't believe the GUI being non-standard, > the image, and the editor being in the image are not among them. And I > don't believe that challenges to those things should go unchallenged > and accepted just because somebody Ah yes another thing which wouuld be nice to have something with one can understand without studying it for years and repeated tries. A simple way of building somewhat resembling GUI applications in Pharo/Squeak. Ah yes flame me that I do appreciate the fantastic Morph world. It's so fantastic that just the developers can build a somewhat "usable" interface with it. Tell me about the "great" applicatons using Morph (anything besides yet another Browser please) > > And yes, I am just as opinionated about my perceptions of the > deficiencies of Python, Clojure, Ruby, Eclipse, Netbeans, ... > Or my frustrations when using them. > I just don't go into those communities expecting them to shape their > favorite tool to my vision. I rather try to use their tools and > attempt to learn their values and ways, assuming they have reason and > purpose for their language and tools. Well at least you get an Editor with Eclipse and Netbeans. But yeah we don't need not stinking Editor. > The biggest problem is people visiting a community and believing they > have the right to speak into that community. If you want that right, > spend some time here. Develop community relations. Then in time you > earn that right to be heard. He has all the right to write what he wants. You have to cope with that, you can agree or disagree. That's up to you but you are not the ape at the door to prohibit his entry. > > I have limited rights to be heard here because I have been a part of > the Squeak/Pharo community for a long time. I have less rights than > others because I haven't contributed anything of consequence. Others > who have been here far less time but have contributed a lot more, have > greater rights. This is poor attitude. Just imagine Denis Ritchie would come here, with no experience of Smalltalk at all. Wouldn't he have the right to state his opinion? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Jan. 18, 2012

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

by Yanni Chiu

On 17/01/12 5:15 PM, Mariano Martinez Peck wrote: > > can you reproduce the problem with that ? Nope, the code worked in both the new and old images. At first I ran the two code snippets in two separate doIt's: "code that geenrates the bug" ... "Code to test the bug" ... Then I tried to run all the code in a single doIt. It worked in all cases.

Jan. 18, 2012

Re: [Pharo-project] Squeaksource Mirror Q&A

by Johan Fabry

Hi GastÃ³n, Thanks for the code, as it serves for 1.4. I will add this to the instructions, marked for 1.4 On 17 Jan 2012, at 18:45, GastÃ³n Dall' Oglio wrote: > mmm, in 1.3 its work, I try with the incorrect 1.3 image.... > Sorry for the noise. > > 2012/1/17 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Hello Johan. > > > - Pharo 1.4 / ObjectAsMethodWrapper issues: The redirect package was written for 1.3, it uses ObjectAsMethodWrapper (i.e. method wrappers). I don't know why ObjectAsMethodWrapper (apparently) is no longer in 1.4 but I would highly recommend including it as it is a very useful package. I thought even the profiler used it. In any case, I welcome any contributions on how to make it work for 1.4 > > In Pharo-1.3-13315 (stable) haven't ObjectAsMethodWarapper. Then in 1.3 and 1.4 evaluate this and get mirror working: > > Gofer new > url: 'http://dsal.cl/squeaksource/ObjectsAsMethodsWrap'; > package: 'ObjectAsMethodWrapper'; > url: 'http://dsal.cl/squeaksource/MonticelloRedirect'; > package: 'MontiRedirect'; > load. > > > Maybe you can add this to HOW TO USE in http://dsal.cl/squeaksource > > Regards. > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Jan. 18, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Chris Cunningham

On Tue, Jan 17, 2012 at 1:40 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > 2) I can understand to put source code in files would make sense 20 years > ago. But I don't think so anymore... a normal notebook has 8gb of RAM these > days. I believe the Windows VM still limits us to around 1/2 gig of image size, at least when starting up the image. If so, it would be nice to not increase the space too much by default (that is, windows users don't really have 8 gig...)

Jan. 18, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Eliot Miranda

On Tue, Jan 17, 2012 at 1:40 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > Well, with the following script it seems I am able to embed all source >> code in trailers: >> >> | trailer source key dict classes | >> dict := IdentityDictionary new. >> CompiledMethod allInstances do: [:aMethod | >> trailer := aMethod trailer. >> source := aMethod getSource. >> trailer sourceCode: source. >> dict at: aMethod put: (aMethod copyWithTrailerBytes: trailer). >> ]. >> dict keys asArray elementsExchangeIdentityWith: dict values asArray. >> >> >> Problem is that after executing the script, when a method is recompiled >> from the system browser, it puts back a trailer with a .changes pointer :( >> I will see if I find where I can change that. >> >> > In another thread, Stefan Marr asked "Is there any general use for such an > embedding, > beside making the finder usable?" > > I would just give my answer: > > 1) From a design point of view, I think that CompiledMethodTrailer is the > correct place where source code should be stored. > I disagree. The changes file is synergistic: - provides crash recovery - removes significant space overhead from the image - changes file plus sources file provide method source history > 2) I can understand to put source code in files would make sense 20 years > ago. But I don't think so anymore... a normal notebook has 8gb of RAM these > days. > it is not just a space trade-off. see above. > 3) I think (I should measure it) that having source code in the image is > faster, even thought that's the least I care about. > certainly. but doing a better job with readOnly copies of the changes file speeds up things a lot. there is no need to keep more than one read-only copy of the changes file. I have old Newspeak code for 3.9 if you're interested. > 4) Ease the logic of pointers in the trailer... > 5) Easy of versioning for a binary serializer ;) so for example in Fuel > we can now be able to serialize compiled methods with trailer that have the > source code. Hence, versioning it (Monticello) is easier. > that's a fair reason. but with parcels having two files, objects (code) and source, worked well, e.g. deploying without source means not including the sources file. > > So...what I would do (that's just my opinion) is: > > 1) always store source code in trailer > 2) do not use .sources anymore > 3) Use .changes ONLY for recovery but not for getting source code > (#getSource) > 4) Provide a way to shrink an image for production cases where people is > interested in image size. Can can very easily replace compiled methods > trailers with empty trailers (zap) and then if it just happens that you > need the sources..you decompile it. > > Maybe there are obvious drawbacks I am not seeing... > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Jan. 17, 2012

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

by Mariano Martinez Peck

On Tue, Jan 17, 2012 at 11:13 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 17/01/12 4:44 PM, Mariano Martinez Peck wrote: > >> I have already opened an issue several months ago: >> http://code.google.com/p/**pharo/issues/detail?id=5005<http://code.google.com/p/pharo/issues/detail?id=5005> >> >> I have also made it as much reproducable as I could and I have also >> asked for help: >> http://forum.world.st/Help-**with-cleanUpForRelease-is-** >> broken-MessageNotUnderstood-**ByteSymbol-run-with-in-** >> tp4205909p4205909.html<http://forum.world.st/Help-with-cleanUpForRelease-is-broken-MessageNotUnder…> >> > > Yep, that's what I'm seeing. You end up with a Symbol where something else > (a CompiledMethod?) is expected. > > I tried the code from the bug report: > > ClassOrganizer cleanUp: true. > Smalltalk > allClassesAndTraitsDo: [ :class | > [ :each | > each > removeEmptyCategories; > sortCategories ] > value: class organization; > value: class class > organization ]. > > It did not cause any problem in either my new or old image (i.e. new is > image derived from current build, and old is the base image I have been > using, which did not have a problem before). > > > No, that was a mistake. The last one I could find to reproduce it is what I wrote in the last email: *" Well.....the maximum I got after a couple of hours is to be able to reproduce it executing TWO times (because the first one works) the following: "code that geenrates the bug" HashedCollection compactAll. Smalltalk removeEmptyMessageCategories. "Code to test the bug" Smalltalk allClassesAndTraitsDo: [ :class | [ :each | each removeEmptyCategories; sortCategories ] value: class organization; value: class class organization ]. If I do only HashedCollection compactAll or only Smalltalk removeEmptyMessageCategories., there is no problem, I can execute the rest without problems. If I do both (no matter which order), then the error happens. Moreover, I tried: (HashedCollection allSubclasses reject: [:each | each = MethodDictionary ]) do: #compactAllInstances. and that does work (no errors). So...somehow, the compact of the MethodDictionary is affecting something...what it is weird is that it only fails if the other code is executed... Anyway, any hint is appreciated. Thanks "* can you reproduce the problem with that ? -- Mariano http://marianopeck.wordpress.com

Jan. 17, 2012

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

by Yanni Chiu

On 17/01/12 4:44 PM, Mariano Martinez Peck wrote: > I have already opened an issue several months ago: > http://code.google.com/p/pharo/issues/detail?id=5005 > > I have also made it as much reproducable as I could and I have also > asked for help: > http://forum.world.st/Help-with-cleanUpForRelease-is-broken-MessageNotUnder… Yep, that's what I'm seeing. You end up with a Symbol where something else (a CompiledMethod?) is expected. I tried the code from the bug report: ClassOrganizer cleanUp: true. Smalltalk allClassesAndTraitsDo: [ :class | [ :each | each removeEmptyCategories; sortCategories ] value: class organization; value: class class organization ]. It did not cause any problem in either my new or old image (i.e. new is image derived from current build, and old is the base image I have been using, which did not have a problem before).

Jan. 17, 2012