March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Inspect it wrong shortcut

by StÃ©phane Ducasse

Tx for reporting. can you open a bug entry? Stef On Mar 3, 2011, at 10:27 AM, tn wrote: > KeyboardEvent keyValue for 'ctrl + i' is evaluated to 9 as ASCII control > code, > and the value conflicts to Character tab value. > I tried to correct source code for this problem. > Below is the workaround for Pharo-1.1.1-OneClickCogVM on Windows XP. > -------------------- > InputEventSensor>>processEvent: > > processEvent: evt > > ... > > "Finally keyboard" > type = EventTypeKeyboard > ifTrue: [ > (evt at: 4)=0 ifTrue: [ "-- add --" > "Sswap ctrl/alt keys if neeeded" > KeyDecodeTable > at: {evt at: 3. evt at: 5} > ifPresent: [:a | > evt > at: 3 put: a first; > at: 6 put: a first; "-- add --" > at: 5 put: a second]. > ]. "-- add --" > "Update state for polling calls" > modifiers := evt at: 5. > ^evt]. > ... > > In order to work this code, Preference Control and Alt keys must be set to > "Full matching". > Because ASCII control characters (e.g. ^i) is mapped to character code with > KeyDecodeTable, only at the time. > > About key event, see InputEventFetcher class comment. > And it is interesting that to contrast implementations between Pharo and > Squeak4.2. > Each implementation is below. > > Pharo: InputEventSensor>>processEvent: > Squeak4.2: EventSensor>>processEvent: > > Thanks, > > > -- > View this message in context: http://forum.world.st/Inspect-it-wrong-shortcut-tp1306494p3333001.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 3, 2011

Re: [Pharo-project] About RPackage

by StÃ©phane Ducasse

On Mar 1, 2011, at 10:57 PM, Tudor Girba wrote: > Hi Stef, > > This was the decisions that two of us (I mean me and you) took :). > > Categories are mapped one-to-one to RPackages. The reason is that this is the simplest path to replace categories in the system. Doru I'm afraid that it will not work because it means that suddenly people will have to change all the configurationOf. We should come up with a smooth transition phase (now this is true that if we could get rid of categories it would be good) > The second step is to map the current Monticello package to RPackages so that we can load existing Monticello packages. > > The third step is to provide saving only of individual RPackages. Thus, Monticello should not save multiple RPackages into one Monticello package, but only make it easy to store each one in a separate package. the problem is that it implies that we will have to change all the configurationOfXXX (or we should shrink all the packages > > Once this is achieved, we can merge an RPackage with a Monticello package, which means that the package that you see in the image is directly storable in a transparent way. > > Cheers, > Doru > > > > On 1 Mar 2011, at 22:44, StÃ©phane Ducasse wrote: > >> Hi cyrille/doru and others. >> >> I do not understand why >> RPackage organizer packages contains System? >> >> In fact all the categories are mapped to packages and I wonder why. >> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >> but it means that in such a case we should merge categories to get back the package we have right now >> else we will end up with loading/saving problems. >> >> >> Stef > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

March 3, 2011

Re: [Pharo-project] Inspect it wrong shortcut

by tn

KeyboardEvent keyValue for 'ctrl + i' is evaluated to 9 as ASCII control code, and the value conflicts to Character tab value. I tried to correct source code for this problem. Below is the workaround for Pharo-1.1.1-OneClickCogVM on Windows XP. -------------------- InputEventSensor>>processEvent: processEvent: evt ... "Finally keyboard" type = EventTypeKeyboard ifTrue: [ (evt at: 4)=0 ifTrue: [ "-- add --" "Sswap ctrl/alt keys if neeeded" KeyDecodeTable at: {evt at: 3. evt at: 5} ifPresent: [:a | evt at: 3 put: a first; at: 6 put: a first; "-- add --" at: 5 put: a second]. ]. "-- add --" "Update state for polling calls" modifiers := evt at: 5. ^evt]. ... In order to work this code, Preference Control and Alt keys must be set to "Full matching". Because ASCII control characters (e.g. ^i) is mapped to character code with KeyDecodeTable, only at the time. About key event, see InputEventFetcher class comment. And it is interesting that to contrast implementations between Pharo and Squeak4.2. Each implementation is below. Pharo: InputEventSensor>>processEvent: Squeak4.2: EventSensor>>processEvent: Thanks, -- View this message in context: http://forum.world.st/Inspect-it-wrong-shortcut-tp1306494p3333001.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 3, 2011

Re: [Pharo-project] About RPackage

by StÃ©phane Ducasse

>> >> Ok I do not remember the protocol. >> we should ask the PackageOrganizer to create a package? >> or just to register it. > > The RPackage class>>named: is an internal method used only by the RPackageOrganizer for creating a package. > > If you want to ensure a package, you should use (I do not like the name :)): yes this is more than registering. this is ensurePackageNamed: > RPackageOrganizer>>registerPackageNamed: aSymbol > ^ packages at: aSymbol asSymbol ifAbsentPut: [RPackage named: aSymbol] > > You can get to the default organizer via "RPackage organizer". > > So, something like: RPackage organizer registerPackageNamed: 'MyPackage' should do it. > >> I have the impression that making sure that a package is registered wen created makes sense since the client does not have to do it and forget to do it. >> So in the PackageInfo logic there are two points; >> - registration >> - query/creation >> >> I have no problem to discard - query/creation >> So to which of these two aspects are you referring to. > > In the current RPackage implementation, #named: is a method meant to be used only internally. The problem with tying creation to registration is that you cannot use multiple Organizers easily (this was the reason why we decoupled the two). > > What we could do is to rename #named: to #newWithName: and have named: be only a compatibility method that does: > > named: aString > ^ RPackage organizer registerPackageNamed: aString Yes good idea. > > > Cheers, > Doru > > > >> Stef >> >>> >>> Of course, we can create a helper method for compatibility reasons, but no internal logic should depend on this. >>> >>> Cheers, >>> Doru >>> >>> >>> On 1 Mar 2011, at 22:59, StÃ©phane Ducasse wrote: >>> >>>> Another point >>>> >>>> RPackage>>named: aString >>>> >>>> | newPackage | >>>> newPackage := self new name: aString ;yourself. >>>> "self organizer registerPackage: newPackage." >>>> ^ newPackage >>>> >>>> does not register the package and this looks suspicion to me. >>>> >>>> >>>> In addition I do not remember the exact logic but the pattern with PackageInfo is that >>>> >>>> PackageInfo named: #foo creates the package if it does exist >>>> >>>> PackageInfo class>>named: aString >>>> ^ PackageOrganizer default packageNamed: aString ifAbsent: [(self new packageName: aString) register] >>>> >>>> So do you remember because it may be better to have the same creation protocol. >>>> >>>> Stef >>>> >>>> >>>>> Hi cyrille/doru and others. >>>>> >>>>> I do not understand why >>>>> RPackage organizer packages contains System? >>>>> >>>>> In fact all the categories are mapped to packages and I wonder why. >>>>> I imagine that this is to avoid to have mostSpecific* logic of packageInfo, >>>>> but it means that in such a case we should merge categories to get back the package we have right now >>>>> else we will end up with loading/saving problems. >>>>> >>>>> >>>>> Stef >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Being happy is a matter of choice." > > > >

March 3, 2011

Re: [Pharo-project] [TODO 1.2] Things to do for 1.2

by StÃ©phane Ducasse

> Hi, > > I wonder if we will ever make it... No dispair :) Just good energy > > Issues needed to be fixed for the Core Image: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.2 Issue 3763: assert failure during Decompiler>>popIntoTemporaryVariable: so far this is not a show stopper. we should have a simpler reproduceable case. so we can move it to 1.2.1 > > Issues needed to be fixed for the Full Image: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage 3620 ---- Accepted Settings: OCompletion settings appear twice not a show stopper > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

March 3, 2011

Re: [Pharo-project] Issue 3620 in pharo: Settings: OCompletion settings appear twice

by pharo＠googlecode.com

Comment #13 on issue 3620 by stephane...(a)gmail.com: Settings: OCompletion settings appear twice http://code.google.com/p/pharo/issues/detail?id=3620 yes.

March 3, 2011

Re: [Pharo-project] Issue 3581 in pharo: [Failing test] 1.1.1 Full: MethodWrappers.Tests.ObjectAsOneTimeMethodWrapperTest.testInstallOnClassCategory

by pharo＠googlecode.com

Comment #5 on issue 3581 by stephane...(a)gmail.com: [Failing test] 1.1.1 Full: MethodWrappers.Tests.ObjectAsOneTimeMethodWrapperTest.testInstallOnClassCategory http://code.google.com/p/pharo/issues/detail?id=3581 I will have a look. now if we cannot reproduce it on the server this is really strange. We can move it as expected failures

March 3, 2011

Re: [Pharo-project] how to load magritte without seaside?

by StÃ©phane Ducasse

Thanks after some fights I got it loading. Gofer it renggli: 'magritte2'; package: 'ConfigurationOfMagritte2'; load. (ConfigurationOfMagritte2 project version: '2.0.6') load: #('Core') On Mar 2, 2011, at 10:43 AM, Esteban Lorenzano wrote: > forget to say that ConifgurationOfMagritte is for Magritte 1, which is some kind legacy... now "bleeding edge" is magritte2 :) > > best, > Esteban > > El 02/03/2011, a las 6:17a.m., stephane ducasse escribiÃ³: > >> Hi guys >> >> how to load magritte without seaside? >> >> Does default means that Seaside2 will be loaded? >> >> Stef >> >> >> ConifgurationOfMagritte>>baseline1211: spec >> <version: '1.2.1.1-baseline' imports: #('1.0-baseline' )> >> >> spec for: #common do: [ >> spec blessing: #baseline. >> spec >> project: 'Seaside2' with: [ >> spec versionString: '2.8.4.3-baseline']; >> yourself. >> spec >> group: 'default' with: #('Core' 'Tests'); >> group: 'Core' with: #('Magritte-Model'); >> group: 'Tests' with: #('Magritte-Tests') >> yourself]. >> spec for: #squeakCommon do: [ >> spec >> group: 'Core' with: #('Magritte-Morph'); >> yourself]. >> >> My old script does not work since Grease is now used? >> >> Gofer new >> renggli: 'magritte2'; >> package: 'Magritte-Model'; >> package: 'Magritte-Pharo-Model'; >> "package: 'Magritte-Seaside'; >> package: 'Magritte-Pharo-Seaside';" >> package: 'Magritte-Morph'; >> "package: 'Magritte-Tests-Model'; >> package: 'Magritte-Tests-Pharo-Model';" >> load. >> >> >> >> > >

March 3, 2011

Re: [Pharo-project] Is there a way to get a merge from a configurationOf?

by stephane ducasse

On Mar 2, 2011, at 12:01 AM, Dale Henrichs wrote: > On 03/01/2011 01:24 PM, stephane ducasse wrote: >> Hi >> >> I would like to know how I can get all the changes (like the merge button in MC) of a configurationOf.... >> >> Stef > > Stef, > > The MetacelloBrowser is getting close to providing something like that ... this morning I just added the ability to get the changes of a loaded package against the stable version, so being able to do so against an arbitrary version is not far from being there ... then firing off a command to open a changes view for each changed package in a config could be done ... > > Asking about merge means that you would like a merge window for each package in a configuration that has a later version in the repository or only merge for dirtied packages ... I do not know. :) My scenario was: I wanted to see the code of ConfigurationOfRPackages and their impact on the system, especially the changes of existing system. > Give me some more details about what you are trying to do and I (or Alexandre) can add it to the MetacelloBrowser then you could take it for a spin ... > > Dale >

March 3, 2011

Re: [Pharo-project] Is it possible to setup Russian fonts in Pharo + Cog VM?

by StÃ©phane Ducasse

FAQ ? On Mar 3, 2011, at 8:35 AM, Geert Claes wrote: > > Dennis Schetinin wrote: >> >> Yes, it works. Thank you! >> > > Great! Dennis, this is probably information more people would want to know > so could you put together a little how-to and share it on the Russian forum? > > ps. Does info like this need to go into http://book.pharo-project.org > somewhere? > > > -- > View this message in context: http://forum.world.st/Is-it-possible-to-setup-Russian-fonts-in-Pharo-Cog-VM… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 3, 2011