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

Re: [Pharo-project] Implementors of...

by Marcus Denker

On May 12, 2012, at 12:12 PM, Marcus Denker wrote: > > On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: > >> Tried from Nautilus: >> >> Why when asking 'implementors of ' in the method menu, I only got the >> implementor of this method. >> > because this "implementors of", not "implementors of..." > We should check... what I against is to have the OB behavior that command-n gets me a list even when I pointed exactly to what I want to have the senders of. >> Am I doing something wrong? >> >> Look like the browser need a lot of love. >> > If you don't like it don't use it. > Another way to say it: We released 1.4 three weeks ago and decided that Nautilus is not yet stable and good enough to be shiped (we never even planed to ship it in 1.4). This means yes, there is work to do. But then, nothing is perfect (and Pharo was actually foundet with the principle of having realized that Perfection is Death :-) So we will improve it, step by step. Every day. This *subsumes* that from the standpoint of tomorrow, we have something imperfect today. There is nothing one can do against it (other than never finishing and releasing anything). Marcus -- Marcus Denker -- http://marcusdenker.de

May 12, 2012

Re: [Pharo-project] Implementors of...

by Marcus Denker

On May 12, 2012, at 11:47 AM, Hilaire Fernandes wrote: > Tried from Nautilus: > > Why when asking 'implementors of ' in the method menu, I only got the > implementor of this method. > because this "implementors of", not "implementors of..." If people really need the other (the one with the menu)? I personally never ever selected something there other than the method itself. If I want to have "senders of" something, I click in the body. > Am I doing something wrong? > > Look like the browser need a lot of love. > If you don't like it don't use it. Marcus -- Marcus Denker -- http://marcusdenker.de

May 12, 2012

Re: [Pharo-project] We need your successes

by Hilaire Fernandes

Nice idea, I will prepare one Hilaire On 11/05/2012 17:11, StÃ©phane Ducasse wrote: > Hi everybody > > We really want to build a "vitrine" showroom of Pharo and we would you to participate. > We want to build a web page with all these successes and show it to the world. :) > > We would like to get from you a three slides document: > > slide one: > a sexy picture and a teaser / who you are. > > slide two: > what is it how cool is it. > > slide three: > what cool pharo techno you used or developed. > > I did a bad one using DrGeo to give you an idea. > > So can you please send us these three slides. We would like to present them during the > Pharo conf and after put them on the web. > > Stef and marcus. > > -- Dr. Geo -- http://www.drgeo.eu

May 12, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by H. Hirzel

On 5/12/12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > got three days meeting this week so crawling to get my brain aligned with > fun againâ¦ > I will read your article. I will also look at STON because I like the object > literal syntax too :). Fine...! > (note that I'm not changing my mind - I still do not get why I need > dictionary for method meta data - I agree; just for method meta data it is not needed. I just checked it in Squeak 4.3, Pharo 1.4, Cuis 4.0 and Amber {#foo -> 1. #bar -> 42} as: Dictionary. "fine for Squeak, Pharo, Cuis" {#foo -> 1. #bar -> 42} gives an Array in Amber; #as: is not understood But a literal array parser available in many dialects is still needed then. For the curly brackets syntax for dynamic array there was some discussion this week on the squeak list how it is used. The decision by Dale and others to go for JSON was driven by the availability of a parser for many Smalltalk dialects. > but we are thinking (and the team should discuss for real and not just > during lunches) that having a literal object syntax would be cool). Great! --Hannes > > Stef > > > >>> I would like to share my quick two cents regarding this subject. >>> >>> 1st cent. I would stick with JSON. Even though I find STON slick, I >>> would >>> not deviate from something that is mainstream and all Smalltalk dialects >>> already support. >>> >>> 2nd cent. A Dictionary literal syntax would be useful too. I would like >>> to >>> have it. >>> >>> It could be something like #{'this' -> 1. 'that' -> 2 }, and keep {1. >>> 2} for >>> dynamic arrays. >> >> I don't want to sound like a broken record - but you do realize that I >> wrote about this in the article and mentioned this exact syntax? >> >> I know, the article was a tad long - but just go to planet.smalltalk.org >> and search down to "Sidestory: Adding literal Dictionaries to >> Smalltalk?". >> >> regards, GÃ¶ran >> > > >

May 12, 2012

Re: [Pharo-project] I cannot see the code in the latest Moose build

by Fabrizio Perin

If we don't use the latest version of Nautilus what about to load the working version of Omnibrowser? Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Dev' 'Dev Tests'). Cheers, Fabrizio 2012/5/11 Tudor Girba <tudor(a)tudorgirba.com> > Now, I switched the build process to use as a seed, the fixed Nautilus > image built on May 4. > > This means that, at this point, in the Moose image Nautilus does not get > updated anymore. > > Cheers, > Doru > > > On 11 May 2012, at 08:52, Tudor Girba wrote: > > > I can reproduce the problem. > > > > Nautilus is loaded from its own repository like: > > Gofer new > > url: 'http://ss3.gemstone.com/ss/Nautilus'; > > package: 'ConfigurationOfNautilus'; > > load. > > (ConfigurationOfNautilus project version: #stable) load. > > > > > > It seems that when you load this in Pharo 1.4, there is a mismatch with > RPackage-Core: if I load the latest RPackage-Core version, it seems to work. > > > > But, if you load the version (213) from the MetaRepoForPharo14, it > works. So, now I changed the loading code to be: > > Gofer new > > squeaksource:'MetaRepoForPharo14'; > > package: 'ConfigurationOfNautilus'; > > load. > > (ConfigurationOfNautilus project version: #stable) load. > > > > > > Nevertheless, it would be good if the ConfigurationOfNautilus would > continue to load properly in 1.4. > > > > Cheers, > > Doru > > > > > > > > On 10 May 2012, at 15:01, Fabrizio Perin wrote: > > > >> Hi, > >> I download the latest yellow build from the moose web site (8 may). > When I open Nautilus I cannot see the code. > >> > >> I don't have any clue if it is about Nautilus or about how Nautilus is > loaded in Moose or about something else. > >> > >> Any idea? > >> > >> Cheers, > >> Fabrizio > > > > -- > > www.tudorgirba.com > > > > "Sometimes the best solution is not the best solution." > > > > -- > www.tudorgirba.com > > "It's not how it is, it is how we see it." > > >

May 12, 2012

[Pharo-project] Copying classes: breaking contract or not?

by Mariano Martinez Peck

Hi guys. The last literal of a instance-side compiled method always points to the SAME (#==) association of the class in Smalltalk global. The literals of a compiled method that refer to class variables refer to the same association (#==) of the classPool of its class: self assert: ((GRPlatform class >> #current) literalAt: 1) == (GRPlatform classPool associationAt: #Current). -> true However, if I do a copy of the class: | copy | copy := GRPlatform copy. self assert: ((copy class >> #current) literalAt: 1) == (copy classPool associationAt: #Current). this is not true anymore. Of course, you can see this because of the Class >> #copy implementation: So my question is....is #copy breaking the contract (and therefore it has to be fixed) or this is not mandatory for the system (as it is with the last literal pointing to classes)? Thanks, -- Mariano http://marianopeck.wordpress.com

May 12, 2012

[Pharo-project] Implementors of...

by Hilaire Fernandes

Tried from Nautilus: Why when asking 'implementors of ' in the method menu, I only got the implementor of this method. Am I doing something wrong? Look like the browser need a lot of love. Hilaire -- Dr. Geo -- http://www.drgeo.eu

May 12, 2012

Re: [Pharo-project] Some user interface suggestions

by StÃ©phane Ducasse

Rick what you can also do is to set up a couple of script so that you set the settings to the value you like. On May 11, 2012, at 7:02 PM, J.F. Rick wrote: > Hi everybody, > > as you might remember, I'm teaching Pharo in an introductory class. I'm finding a few rough edges with Pharo and was wondering whether people could help me. I'm using Pharo 1.3 with the CogVM on Mac OS X Lion. > > One problem I have is with fullScreen mode. First, I could no longer figure out how to go into fullScreen mode from the menus. Is this something that Pharo users don't do? If so, that seems a real shame. I then used the command (Display fullScreen: true). That worked, but, when I'm in fullScreen mode, I can no longer Alt-Tab between applications or workspaces. Is this a CogVM problem? Is it just that that's no longer the accepted way to go into fullScreen mode? > > In the class I'm doing live coding, basing a lot of stuff on showing something in a Workspace and having students work on problems to print to the Transcript (we are still on very basic for loops and have a while to go before they can use the browser to create classes). I use the Workspace to just list the things that I want to cover on that day. This is a mixture of plain text and code snippets. Kudos on being able to employ native fonts. I was able to use a big font that works well on the projector. Here are a few things I wish I could do: > 1) Turn off syntax highlighting (already implemented) and programming-specific input (not enabled). When I just write a piece of text, it thinks I'm trying to write a message name. If I add a [, it adds the matching ]. Syntax highlighting and programming-specific input could be separate things, but they could also go together (i.e., you turn off one, then you turn off the other). For my use, I'd ideally want to switch off both highlighting and input help. yes > 2) On a small note, when you turn off syntax highlighting, the workspace retains the current font. Ideally, it should switch everything to a black default font. > 3) I'd like to be able to bold some text to make it appear like a heading (e.g., Assignment 3). With Squeak, you could just bring up the halos, get down to the text, and change the aspects. With halos gone, I don't know of a way to do this. Perhaps it would at least make sense to move some of that lost functionality to the contextual menu. > 4) When I change the global font for workspace content, it does not affect existing workspaces. Considering how well the redecoration of system windows works, I'd expect that to work as well. I think that I fixed that in 1.4 because Text usage did not honor the setting. > 5) There are some awkward bits to the programming-specific input. Here's one that happens to me all the time. I have incorrectly placed the boundaries of a block. I delete the [ from the original location. I go to the new location to place it. I enter in [, but get []. To get what I want, I have to hit [, right arrow, and backspace. This is even worse for trying to add an extra ' to a place it is missing. I press ' and get ''. I find my cursor in the middle, so I hit backspace. Instead of deleting one ', it deletes both. Wouldn't it make more sense to have a backspace delete the automatic addition; that's the way most auto-correct systems work. So, [ + backspace produces [ and ' + backspace produces '. I think that would be more intuitive. Yes sometimes the system is confused. In 1.4 we starting to clean the mess around Ocompletion/ecompletion and we should continue. > > Cheers, > > Jeff > > PS Overall, I'm pretty happy with Pharo. It definitely has fewer rough edges and a smoother interface than Squeak. That's important for my students. Thanks. Jeff could you open one issue per problem so that we can tackle them one by one. I would be really interested by the exercises you propose. Also improving ProfStef. So if you have ideas :)

May 12, 2012

Re: [Pharo-project] [BUG]: Nautilus won't launch

by Esteban Lorenzano

yes... we need to iterate over RPackage soon :) On May 12, 2012, at 10:37 AM, StÃ©phane Ducasse wrote: > may be you found a bug in the integration of RPAckage to the system. > Unloading or removing a class may not be refreshed in the packages. > > > On May 11, 2012, at 8:22 PM, Sean P. DeNigris wrote: > >> Issue 5867: [BUG]: Nautilus won't launch >> http://code.google.com/p/pharo/issues/detail?id=5867 >> >> I don't understand the problem exactly, but this fixes it: >> >> RPackageOrganizer default packages do: [ :e | >> (e instVarNamed: #classExtensionSelectors) removeKey: >> #FlatMessageListBrowser ifAbsent: [] ] >> >> -- >> View this message in context: http://forum.world.st/BUG-Nautilus-won-t-launch-tp4627226.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

May 12, 2012

Re: [Pharo-project] [BUG]: Nautilus won't launch

by StÃ©phane Ducasse

may be you found a bug in the integration of RPAckage to the system. Unloading or removing a class may not be refreshed in the packages. On May 11, 2012, at 8:22 PM, Sean P. DeNigris wrote: > Issue 5867: [BUG]: Nautilus won't launch > http://code.google.com/p/pharo/issues/detail?id=5867 > > I don't understand the problem exactly, but this fixes it: > > RPackageOrganizer default packages do: [ :e | > (e instVarNamed: #classExtensionSelectors) removeKey: > #FlatMessageListBrowser ifAbsent: [] ] > > -- > View this message in context: http://forum.world.st/BUG-Nautilus-won-t-launch-tp4627226.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 12, 2012