December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Can't browse slices in Inbox

by Michael Roberts

I've noticed similar issues with slices. I am finding it difficult to narrow down the exact problem. Can we build up some entries on the tracker? then we can review them all. cheers, Mike 2009/12/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: > However, in my opinion, Pharo or whatever, has an "issue" with the following > situation: > > - Modify class of a certain package. > - create a new package (maybe called Slice-XXX...). > - Open monticello browser, select the package Slice-XXX, right button, "add > all dirty packages as required". > - Browse the package Slice-XXXÂ and you will see that "seems to be empty". > It does not show the changes of its requiered packages. > > Cheers, > > Mariano > > On Tue, Dec 8, 2009 at 3:15 AM, Martin McClure <martin(a)hand2mouse.com> > wrote: >> >> Martin McClure wrote: >> > In a Monticello browser on the PharoInbox, I haven't been able to browse >> > slices. When I press the Browse button I get a browser "Snapshot of >> > SLICE...". In the class category pane the only thing listed is >> > '*Extensions' and that has nothing in it. >> > >> > Is this a bug, or am I going about this wrong? >> >> The latter. I see now -- a slice is truly empty. I was being confused by >> an earlier description of "slice" in MC2. >> >> -Martin >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 13, 2009

Re: [Pharo-project] [update 1.1] #11097

by Mariano Martinez Peck

On Sun, Dec 13, 2009 at 5:39 PM, Marcus Denker <denker(a)acm.org> wrote: > > On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote: > > > > > > > On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker(a)acm.org> wrote: > > > > > IMHO we should also check senders in Pharo and Pharo Web. Pharo core in > itself is nothing. Pharo is the platform for other tools. We have the dev > and web image. We should take care about the packages that are loadable in > Pharo. I am not saying not to remove the method, but at least, to check in > dev and web images and if there are senders, send an email to the > developers/maintainers notifying about this change. Even if the messages > shouldn't be part of the API. With this we avoid possible DNU at runtime. > Not all the external packages covers a good percent of tested code in their > unit tests. > > > > > > > Yes... but there is really stuff that nobody needs. > > > > > > Yes, of course. But for example, the other day ifNil:ifNotNilDo: and > ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for > example O2. > > > > No, I just change all senders of those methods... to use the one without > Do:, which is inlined and thus much faster. And nicer. But I left the > methods for now. > (I did not even deprecate them, as they tend to be used a lot) > Sorry, I misunderstood you then. I thought you have removed them :) > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 13, 2009

Re: [Pharo-project] Keyboard Shortcuts in Pharo?

by Benjamin Pollack

On Fri, Dec 11, 2009 at 2:44 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Safara was an attempt to implement a replacement for the current text > editor, where nothing was hardcoded but everything could be configured > by the tool (highlighting, completing, shortcuts, ...). Unfortunately > this project never made it into a useable state. Writing a text editor > is difficult. > > I hadn't heard of Safara, but SVI ( http://map.squeak.org/package/ab5ae6be-b705-40a2-8d63-a992442086ec) is (in my opinion) a very successful attempt at modernizing the editor. It comes with vim- and Emacs-like keybindings, which include shortcuts for selecting and navigating through blocks, paren groups, messages and the like--exactly what we're talking about here. It doesn't run on Pharo or trunk Squeak, but it worked just fine in heavy use for me on Squeak ~3.6 through 3.9. I don't have the time to make it run on Pharo right now, but I doubt someone with sufficient motivation would have *that* much of a problem getting it running comfortably. If I recall correctly, the main effort was going to be updating the OmniBrowser integration. --Benjamin

Dec. 13, 2009

Re: [Pharo-project] SqueakMap code into Pharo?

by Monty Kamath

> You go to the SqueakMap website (http://map1.squeakfoundation.org/) > navigate to the project, download the release and drag&drop it into > the Pharo image. Thanks for the info. That is just what I was looking for! -- View this message in context: http://n2.nabble.com/SqueakMap-code-into-Pharo-tp4157808p4160199.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2009

Re: [Pharo-project] Keyboard Shortcuts in Pharo?

by csrabak＠bol.com.br

Em 13/12/2009 11:11, Mariano Martinez Peck <marianopeck(a)gmail.com> escreveu: Thinking aloud, I wonder if isn't better to have the 'feature' of duplicateAllControlAndAltKeys its sibbling duplicateSomeControlAndAltKeys removed and have only the Alt prefix for the Pharo related operations? -- Cesar Rabak

Dec. 13, 2009

Re: [Pharo-project] [update 1.1] #11097

by Marcus Denker

On Dec 13, 2009, at 5:39 PM, Marcus Denker wrote: > > On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote: > >> >> >> On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker(a)acm.org> wrote: >> >>> IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests. >>> >> >> Yes... but there is really stuff that nobody needs. >> >> >> Yes, of course. But for example, the other day ifNil:ifNotNilDo: and ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for example O2. >> > > No, I just change all senders of those methods... to use the one without Do:, which is inlined and thus much faster. And nicer. ... and that was for ifNotEmptyDo:, refactoring to call ifNotNil: ist on the TODO (hundrets of senders... ParseTreeRewriter to the rescue. Marcus

Dec. 13, 2009

Re: [Pharo-project] [update 1.1] #11097

by Marcus Denker

On Dec 13, 2009, at 4:48 PM, Mariano Martinez Peck wrote: > > > On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker(a)acm.org> wrote: > > > IMHO we should also check senders in Pharo and Pharo Web. Pharo core in itself is nothing. Pharo is the platform for other tools. We have the dev and web image. We should take care about the packages that are loadable in Pharo. I am not saying not to remove the method, but at least, to check in dev and web images and if there are senders, send an email to the developers/maintainers notifying about this change. Even if the messages shouldn't be part of the API. With this we avoid possible DNU at runtime. Not all the external packages covers a good percent of tested code in their unit tests. > > > > Yes... but there is really stuff that nobody needs. > > > Yes, of course. But for example, the other day ifNil:ifNotNilDo: and ifNotNilDo:ifNil: were removed. And maybe are packages that use them, for example O2. > No, I just change all senders of those methods... to use the one without Do:, which is inlined and thus much faster. And nicer. But I left the methods for now. (I did not even deprecate them, as they tend to be used a lot) Marcus

Dec. 13, 2009

Re: [Pharo-project] Regarding the shortcuts

by csrabak＠bol.com.br

Em 13/12/2009 07:03, Michael Rueger escreveu: > csrabak(a)bol.com.br wrote: > > Well then be sure they're not 100% working. Also, we should get a > > way of having the shortcuts less dependent on platform (ex. the > > prefix key to what we need to find a way of referring to them in > > an homogeneous way like, say, Emacs). > being a long time smalltalk user, how does Emacs do it? Emacs coming from an old heritage and being multiplataform as well, 'standardized' the names Control and Meta, this last one normally maps to Alt key in PCs but it is called Meta in Workstations. There is no need to explicitly talk about Shift if you are only working with alphanumeric shortcuts, if we decide to employ the ten to twelve "function keys", then the Shift prefix has to come in play. > In Sophie we used I think shift, command, control to identify the > modifier keys and mapped them in the platform classes to the > platform specific bits. We also had a key dispatcher class with > instances configured for the different views so that all the > modifier etc handling was done in one place. IIUC 'command' can be the name we use for the command key in Macs and Alt for PCs, we've only to create a nomenclature, stick to it and use it consitently in the program and documentation. > > > In PBE book a change was done towards a unified terminology for > > the mouse buttons. I know still there are some issues with that, > > but let's move on! > What are the issues? Certain operations which used to be available on the three button mice now only work if you prefix the button with a Ctrl, and this behaviour it is not consistent, so from times to times you've to do an heuristic search of the menu you want to appear... -- Cesar Rabak

Dec. 13, 2009

[Pharo-project] Unsent selectors in CompiledMethod

by Igor Stasenko

Hello guys, there are few unsent messages on class side of CompiledMethod, primitive: primNum numArgs: numArgs numTemps: numTemps stackSize: stackSize literals: literals bytecodes: bytecodes trailer: trailerBytes and newBytes: numberOfBytes trailerBytes: trailer nArgs: nArgs nTemps: nTemps nStack: stackSize nLits: nLits primitive: primitiveIndex flag: flag I checked both in Pharo 1.1-core and in Trunk images, both of them seem having no senders. Any insights if it safe to wipe them out? -- Best regards, Igor Stasenko AKA sig.

Dec. 13, 2009

Re: [Pharo-project] [update 1.1] #11097

by Mariano Martinez Peck

On Sun, Dec 13, 2009 at 4:31 PM, Marcus Denker <denker(a)acm.org> wrote: > > > IMHO we should also check senders in Pharo and Pharo Web. Pharo core in > itself is nothing. Pharo is the platform for other tools. We have the dev > and web image. We should take care about the packages that are loadable in > Pharo. I am not saying not to remove the method, but at least, to check in > dev and web images and if there are senders, send an email to the > developers/maintainers notifying about this change. Even if the messages > shouldn't be part of the API. With this we avoid possible DNU at runtime. > Not all the external packages covers a good percent of tested code in their > unit tests. > > > > Yes... but there is really stuff that nobody needs. > > For the other, we should just put removals on the bugtracker and make sure > that we check with the main image before removal... > > +1 > In general, I hope to revisit the idea of supporting software evolution in > the language... see e.g. the paper > http://scg.unibe.ch/scgbib?query=Nier08b&display=abstract for some > thoughts of what is needed. > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 13, 2009