- Pharo-dev - lists.pharo.org

[Pharo-project] STON Update
by Sven Van Caekenberghe Dec. 1, 2012

Dec. 1, 2012

Hi, Based on feedback by Norbert Hartl, Stuart Herring and Dale Hendrichs (thank you) I improved the current STON version a bit. http://ss3.gemstone.com/ss/STON https://github.com/svenvc/ston Changelog: A nasty cycle bug was fixed Performance was improved, especially for large structures. Some implementation changes (recursion done using a stack, stonProcessSubObjects: optimized using stonContainsSubObjects) I did some stress/performance testing/tuning. Using STONTestMap classTreeExtended. to generate a structure mimicing the class hierarchy, with objects for all classes, about 7000 in my image and all methods, about 64000 in my image, with super/subclass and method owner links to create cycles. This results in a 7 Mb .ston file. The normal code, serializes this in 28 seconds and materializes it in 11.5 seconds. The 'fast' versions (using ZnBuffered[Write|Read]Streams and Fuel Large Datastructures) does it in 1.1 and 3.8 seconds respectively. New users are always welcome. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

2 7

[Pharo-project] CogVM crash code
by Jon Anderson Dec. 1, 2012

Dec. 1, 2012

Hi all, I don't post to lists often, but I thought some of you might be interested in these few lines of code that crash the CogVM on both Linux and Windows. File-in the Smalltalk code below, then evaluate [nil crashCogVM]. The code uses [1-1] but it could use [1+1] or [56+98]. I put the code on nil, but that is not important either. I think the important thing is that the primitive (+ or -) is evaluated but the result is not assigned into any variable. Also important is that the code is put into a loop that I assume has been JIT optimized. The image I used is Pharo 1.4 one-click with latest update #14459. This code does not crash StackVM. Have fun! - Jon. !UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'! crashCogVM " Evaluate [ nil crashCogVM ]" | i | i := 20. 1 to: i do: [:d | 1-1 ] ! !

5 5

[Pharo-project] About ArrayedCollection and at:/put:
by Igor Stasenko Dec. 1, 2012

Dec. 1, 2012

It says: "I am an abstract collection of elements with a fixed range of integers (from 1 to n>=0) as external keys." now that leaves me clueless, why then it does not defines (introduces) a protocol: #at: and #at:put: at least as an abstract one , i.e. subclassResponsibility is it because they are already in Object protocol? And because subclasses (like Array) using default #at: implementation? I don't know, but i think Object should not have #at:/#at:put: protocol.. because: - it applicable only to variable subclasses - many classes have own implementation of it - the behavior behind this is to access a variable fields . while other classes use this protocol for higher abstractions (like dictionaries) so, to my thinking, Object should not define this protocol.. for this purpose we having #basicAt:/put: methods. btw, just an idea to clarify things even more, we could rename them to variableAt: [put:] (or any other name which properly tells that method provides an access to variable fields of object). -- Best regards, Igor Stasenko.

3 2

[Pharo-project] Comments in Packages?
by Sebastian Nozzi Dec. 1, 2012

Dec. 1, 2012

Dear Pharoers, by chance I read recently a comment from Stef that comments for Packages are planned. Is this true? Would be a very welcome feature :-) Sometimes I load a package, or series of packages, from Monticello, but have a hard time figuring out where to start. Through intuition, trial and error I find the "core" package and then the "core" class and then at the class side maybe there are examples, or look in the documentation. But a better starting point would be of course documentation (just a few lines) in the core package. Long story short, we need a way to compensate for the lack of "README.txt" that file-based solutions have ;-) Also related: is there a way to execute a command after a class/package is loaded by Monticello? Like opening a Workspace with initial documentation? Thanks! Sebastian

2 1

[Pharo-project] Changes in announcements
by Ezequiel Lamonica Dec. 1, 2012

Dec. 1, 2012

Hi, I was reviewing with Esteban about the lack of some announcements in the system and some bugs in other ones. I've been working on that for this week. This is the list: -MethodRename -Snapshot -Session (i don't know if this is necessary) -VariableAdded (one for every kind) -VariableRemoved (one for every kind) -Protocols (add/modif/remove/rename) -TraitComposition - When a package is created, the announcement is not released This only happens when a class is created with that category. -When I modify a class and also I change its category, then only class recategorized announcement is sent -Package removed is not sent

3 2

[Pharo-project] 20381 running the test does not work ...
by StÃ©phane Ducasse Dec. 1, 2012

Dec. 1, 2012

There is a bug blocking the image. SubscriptOutOfBounds: 0 in the SystemProgressMorph class updateJob:

4 15

Re: [Pharo-project] Vim Keys?
by Igor Stasenko Dec. 1, 2012

Dec. 1, 2012

On 1 December 2012 01:22, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > the bottom line is this, may I as a noob user use system browser without the > mouse , just by shortcuts ? How about the debugger and inspector ? > > Personally I dont care about vim shortcuts, I am an emacs user and guess > what I dont care about emacs shortcuts as well. This why there is no way I > am going to bother implementing vim shortcuts which by the way I find them > bad , and so do I emacs shortcuts as well. So we are not far apart on this > point. > > But I will try to implement a shortcut based interface. I wish I could > figure out pharo in a single day and start doing this stuff. But learning > takes time. From time being mouse does not bother because I code slow > anyway, but I think the faster I start to code in pharo the more it will > make sense to rely more on shortcuts and liberate myself from them mouse. > > Also I think you are unfair calling emacs a text editor. Its not. I know the > consensus is calling emacs a text editor but I dont think thats a fair > definition. Because taking a look into emacs will immediately show that is > not that diffirent from smalltalk. Its a development enviroment. It has its > own language, a very capable one, rich library set not just limited to text > editing and an array of development tools. If you add to it a common lisp > runtime together with slime , it can give pharo easily a run for its money. > I am saying this because you talked about shortcuts of making things "bold" > or "italic". > i know that emacs is not just text editor. but i never used it anyways, so i don't know and don't relly care :) but my "bold" or "italic" was about some features would make sense only in certain environment/ for certain purpose. If you need apples but people offer you oranges.. you won't buy them despite how fresh and juicy and low-pricey they are. And even if you buy, it won't fulfill your need in apples. That means that if you blindly port feature(s) from one environment into another, it is not necessary makes sense, despite how good and useful they are. First thing what you should do is to study deeply both of them, and then you'll have an insight whether doing some moves makes sense. > In any case I don't think its unreasonable from time to time a new user to > jump in here and ask for a feature. This also gives a clear idea what people > want from pharo, old and new users. Whether a developer will jump in and > implement the feature is a completely different matter. After all that's the > beauty of a truly democratic system. > yes.. but what makes me sad that most newcomer initiatives look like following: - hi i am new here - lets improve Pharo by porting X features into it, because X is cool. and then they disappear. By analogy, imagine i started using emacs.. a few days later i will have a bright idea, how cooler it would be to have vim shortcuts in it.. and next step, i will jump into emacs dev mailing list and bring that proposal on table! That will "give a clear idea" where emacs developers should focus their effort for next release. No doubt. :) All i can tell is, that this is not Pharo problem. The problem is that people tend to think that things they already learned or get used to so far is best of best, and anything which does not fits into their world view or using different approach alienating them a lot. The first reaction is to just leave, and second one is to bring as much baggage as they can into new environment, hoping that it will make it less alien. This , of course applicable to everyone, including me, because it is natural behavior of humans :) But here lies a mistake: first you must learn it well. And only then you can judge whether your 'baggage' could make things better or not. -- Best regards, Igor Stasenko.

1 0

[Pharo-project] Fw: Vim Keys?
by dimitris chloupis Dec. 1, 2012

Dec. 1, 2012

the bottom line is this, may I as a noob user use system browser without the mouse , just by shortcuts ? How about the debugger and inspector ? Personally I dont care about vim shortcuts, I am an emacs user and guess what I dont care about emacs shortcuts as well. This why there is no way I am going to bother implementing vim shortcuts which by the way I find them bad , and so do IÂ emacs shortcuts as well. So we are not far apart on this point. But I will try to implement a shortcut based interface. I wish I could figure out pharo in a single day and start doing this stuff. But learning takes time. From time being mouse does not bother because I code slow anyway, but I think the faster I start to code in pharo the more it will make sense to rely more on shortcuts and liberate myself from them mouse. Also I think you are unfair calling emacs a text editor. Its not. I know the consensus is calling emacs a text editor but I dont think thats a fair definition. Because taking a look into emacs will immediately show that is not that diffirent from smalltalk. Its a development enviroment. It has its own language, a very capable one, rich library set not just limited to text editing and an array of development tools. If you add to it a common lisp runtime together with slime , it can give pharo easily a run for its money. I am saying this because you talked about shortcuts of making things "bold" or "italic".Â In any case I don't think its unreasonable from time to time a new user to jump in here and ask for a feature. This also gives a clear idea what people want from pharo, old and new users. Whether a developer will jump in and implement the feature is a completely different matter. After all that's the beauty of a truly democratic system. ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: Pharo-project(a)lists.gforge.inria.fr; dimitris chloupis <thekilon(a)yahoo.co.uk> Sent: Saturday, 1 December 2012, 0:06 Subject: Re: [Pharo-project] Vim Keys? On 30 November 2012 20:25, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > Even though I agree with your Igor , text editing is not per se required by > existing smalltalk users, though even that is debatable, introducing vim and > emacs mapping, in a completely optional state, will be definitely a > motivation for vim and emacs user to join pharo. For example if you enter > the pharo channel in irc you will be happy to find one person talking to > himself, squeak channel more or less the same. Both #emacs and #vim show how > popular both of these text editors are, why not pharo attract that crowd. > Let me throw a crazy idea on the table why smalltalk cannot be a more > ultimate text editor than those. Sure its ton of work and definetly you or I > should not do , but I am sure if we provide minimum means of people to do > this we will see more and more people porting vim and emacs features to > pharo. i am not against it. I just a bit tired of seeing this recurring topic appear again and again and no action. Come on, people. Pharo is open-source project. If you need it so badly, then do it. Don't wait till someone, one day do it for you, and stop wasting time, repeating same arguments over and over again, how good vi/emacs mappings are comparing to what we having now. > > Also your point that we dont need text editing that much in pharo , is vaild > from one side, however you should not forget that even though vim and emacs > might appear radically diffirent from pharo those diffirences are skin deep. > All of them have IDE tools , code navigation tools, debuging tools etc ... > so I am not that convinced that for example using system browsers via > shortcuts cannot be improved. > it can and should be improved. Absolutely. But pharo environment is much more than text editing, and so, asking if it can provide "vi mapping" to me sounds similar to "can photoshop provide vi/emacs mapping" , i.e. makes no sense at all. apart from this is implementing a full-fledged text editor/word processor: it is doable and been done before (like Sophie project did). But this is completely orthogonal to IDE: i simply do not see how shortcuts like making text "bold" or "italic" could significantly improve my daily coding experience. For coding i concerned about completely different things: code navigation, browser etc.. And here is where shortcuts come in handy.. Now if someone tell me how "senders of it" action shortcut (to browse senders of selector) which i often using by pressing 'Cmd-n' can be ton times more convenient to use, once we will use vi shortcut for it (btw, what is default vi shortcut for such action?)... i am all ears. > I am actually in the process of learning elisp code to port some of the > features of emacs to pharo. > -- Best regards, Igor Stasenko.

1 0

Re: [Pharo-project] CogVM crash code
by Jon Anderson Nov. 30, 2012

Nov. 30, 2012

I added the issue. It is #109. > uuh nasty :), also happens under 2.0 ;) > could you open an issue on the cog issue tracker with the contents of this email? > https://code.google.com/p/cog/issues/list > thanks

1 0

[Pharo-project] Trying Athens
by Casimiro de Almeida Barreto Nov. 30, 2012

Nov. 30, 2012

I've had strange problem with Pharo 2.0: it times out at Gofer. For instance: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. Will spend the 30secs timeout & then give-me a debugger window complaining that could not connect. But network is OK and Pharo 1.4 does not have this problem. Besides, Pharo 2.0 updates OK (so, again, there's no network problem). CdAB

2 5