- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About ArrayedCollection and at:/put:

by Camillo Bruni

On 2012-11-30, at 11:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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 => definitely should be abstract > 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. yup I think the same way. Happened to already too many times that I call #at:put: on a random object and to my surprise it worked :P > 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). on simple collections: #at:put: => #basicAt:put: on normal objects: #fieldAt:put => #basicAt:Put: I prefer fieldAt: since it is not always the instance variable you access like on variableSized objects where you simply access an item. Also it goes along the naming convention we had in our slot paper ;)

Dec. 1, 2012

Re: [Pharo-project] Changes in announcements

by Camillo Bruni

nice! On 2012-11-30, at 10:43, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks ezequiel. > > Stef > > On Nov 27, 2012, at 11:09 AM, Ezequiel Lamonica wrote: > >> 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 > >

Dec. 1, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by Camillo Bruni

On 2012-11-30, at 18:15, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > camillo > > one of the problem that we have is that the refactoring stopped in the middle > because displayProgressFrom: minVal to: maxVal during: workBlock now works with job and this is nice > but job requires but all the user of displayProgressFrom: minVal to: maxVal during: workBlock > are using bar current: aNumber and not a value between 0 and 1.0. > > So this means that we will a lot of broken code. > Am I correct? right now Job works still with min/max/current so I still have to do the full transition. Ideally no code will be broken, since most people use progress bars via one of the public interfaces, either on String, Collections or directly on the UI Manager. => these will be the main places to change it. I think I can have a look at it today or tomorrow and finish the refactoring.

Dec. 1, 2012

Re: [Pharo-project] [[ false ] whileFalse: [ ]] in workspace

by Sebastian Nozzi

It's the #7076. 2012/11/29 Camillo Bruni <camillobruni(a)gmail.com>: > perfect! can you open a bug report with this information? :)

Dec. 1, 2012

[Pharo-project] Comments in Packages?

by Sebastian Nozzi

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

Dec. 1, 2012

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

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.

Dec. 1, 2012

[Pharo-project] Fw: Vim Keys?

by dimitris chloupis

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.

Dec. 1, 2012

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 23:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Nov 2012, at 23:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> And here is where shortcuts come in handy.. > > Igor, you are not even using Command-Enter to search for classes/methods last time we sat togetherâ¦ ;-) > the explanation is much easier than you think: in my dev image, which i didn't updated for a while, this function is non-existent. i find myself that, time to time i pressing this magic key combination, get nothing.. and then enduring and continue the old way. :) but from other side, i bet you're not using my little patch to treat multiple white-space characters as a single entity for cursor movement, while i enjoying it :) > Like Command-Click on Class/method names, so cool and technically not keyboard shortcuts ! > yes i like it.. but same issue: i do not change images that often. > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > -- Best regards, Igor Stasenko.

Nov. 30, 2012

Re: [Pharo-project] Vim Keys?

by Igor Stasenko

On 30 November 2012 22:17, âking <rkingdesk(a)sharpsaw.org> wrote: > On 11/30/2012 12:13 PM, Igor Stasenko wrote: >> well, what you explaining here is not just about handling keyboard >> typing, but also >> requires changes in UI (showing command line, black & white color >> scheme, 80x25 text mode ;) ) etc.. > > I know you're joking, but limiting one's self to 80 columns is generally > a good way to maximize screen space. Step back and look at code that > runs with really long lines, and you'll see a vast emptiness on most lines. > yeah yeah. I can even remember that Bill Gates once said that 640kb of RAM is more than enough for any application. and, btw do you know that color of a blue sky is bad for your sight? :) >> i think, if vi would contest for "best obscure editor", i guess it >> would get 1st prize. i don't really care why you like it , just can you >> (or someone else) explain me, why you think it is best possible way of >> doing things? Since i can't see it. > > Monkey-bopping not a compelling argument? > In that sense, a software which works is the only compelling argument to me :) But since i knowing a bit about VI style of text editing, what you propose is not quite compelling to me. Once i tried hard to become 'pro' vi user and tried to remember all its commands/shortcuts.. but failed miserably after a while.. It looks like i am too spoiled by modeless text editors.. and nothing can change my brain patterns. Because the very first text editor for coding, which i was using around '86 was like hundred times more convenient comparing to what i seen in vim once first time i tried to learn it around 2000's. > I mean, the goal is to make a fluid interface. > The subtitle of one of > the vim books is "Edit at the Speed of Thought". That's the key thing. i am quite happy with the speed at which i editing right now. :) besides 'fluid interface' is too vague, and adding 'vi' label to it sounds even more fuzzy to me. What i understand that you want to see/make certain improvements in Pharo. And i appreciate that. > When I'm coding with vi keys, the text just goes where I want it, and > quickly, with very little stopping to think about it. > same here, except that i don't use vi keys :) >> What exactly commands/shortcuts you wanna have there? >> And wouldn't it be better to focus UI design towards avoiding the need >> for shortcuts/modes alltogether? > > Possibly. I'll think about that. > >> After all, you can run vi/emacs/<put your favorite> in separate window, >> and can always copy-paste text between, and enjoy your lovely keyboard >> shortcuts. > > This is something that Pentadactyl (a amazing Firefox plugin that makes > the browser vim-like) does. You can hit Ctrl+i on any text field, and it > pops up a gvim window with that text. Perhaps something like this is > sufficient. > > We'll see. My problem right now is that I have dozens of projects that > steal my free time from getting into Smalltalk, but I'll fix that as > soon as I can. > > ââ > > -- Best regards, Igor Stasenko.

Nov. 30, 2012

[Pharo-project] STON Update

by Sven Van Caekenberghe

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

Nov. 30, 2012