- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Question on 2.0 : shortcuts for menu items

by Guillermo Polito

Be careful that Cmd r is used for rename in Nautilus also... Maybe for reformat code something like cmd shift f can be used ($f cmd shift). On Fri, Jul 13, 2012 at 5:24 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Ok, done. If anybody is missing the format (Ctrl+r) command in Nautilus, > here it is done. > > Now you can write code to the kilometer, and press Ctrl+r, Ctrl+s. Et > voilÃ , nicely formatted smalltalk code. > > Issue 6363: Format command (linked to Ctrl+r) > > Slice uploaded to Pharo Inbox. > > Thierry > > > Le 13/07/2012 15:57, Goubier Thierry a Ã©crit : > >> Le 13/07/2012 15:45, Benjamin a Ã©crit : >> >>> in a workspace evaluate >>> >>> KMLog setDebug >>> >>> Open a Transcript, and it will tell what ctrl+r is used for :) >>> >> >> It only tells you [Ctrl+r] :-( >> >> Just noticed that my changes to NautilusUI were not taken in account >> anyway. >> >> Thierry >> >> >> Ben >>> >>> On Jul 13, 2012, at 3:44 PM, Goubier Thierry wrote: >>> >>> Le 13/07/2012 15:36, Benjamin a Ã©crit : >>>> >>>>> command r is already used (to rename stuff) >>>>> >>>> >>>> But it triggers on Alt+r, not Ctrl+r. >>>> >>>> Ctrl+r is caught, but I don't know by what. >>>> >>>> I'll try to change the key (or the rename key). >>>> >>>> Trying to follow the KM areas, but lost in a maze of small classes, >>>> all identical. How do you guys manage that ? >>>> >>>> Thierry >>>> >>>> try a key not used like h >>>>> >>>>> Ben >>>>> >>>>> On Jul 13, 2012, at 3:32 PM, Goubier Thierry wrote: >>>>> >>>>> Le 13/07/2012 14:42, Benjamin a Ã©crit : >>>>>> >>>>>>> (aBuilder shortcut: #Foo) >>>>>>> category: #NautilusSourceCodeShortcuts >>>>>>> default: $r command >>>>>>> do: [:target | self formatTextFor: target sourceTextArea ] >>>>>>> description: 'Format the text of a text morph'. >>>>>>> >>>>>>> Defined on class side of the class you want :) >>>>>>> >>>>>> >>>>>> Found that, yes. >>>>>> >>>>>> Doesn't work... >>>>>> >>>>>> Cmd+r result in a tab (well, if Ctrl+r is really Cmd+r in Linux). >>>>>> >>>>>> Thierry >>>>>> -- >>>>>> Thierry Goubier >>>>>> CEA list >>>>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>>>> 91191 Gif sur Yvette Cedex >>>>>> France >>>>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > >

July 14, 2012

[Pharo-project] Shouldn't FixedFaceFont die?

by phil＠highoctane.be

I am digging into the font system. FixedFaceFont doesn't seem that much used anywhere. Phil

July 14, 2012

Re: [Pharo-project] Synchronizing system time

by Denis Kudriashov

2012/7/14 Camillo Bruni <camillobruni(a)gmail.com> > > On 2012-07-14, at 11:37, Denis Kudriashov wrote: > > > I think, you dont understand me. > > > > Getting current date and time not reflects system time changes. > > Just start pharo then change your windows system time and execute > > "DateAndTime now". > > It will return wrong datetime. > > > ah, ok, then that is clearly broken! yay Yet another substantial > DateAndTime bug > > > So question: > > how to reinitialize DateAndTime in such situation to get right system > date > > and time? > > most probably :) > > can you open a bug report with a reproducible description? > done http://code.google.com/p/pharo/issues/detail?id=6374

July 14, 2012

Re: [Pharo-project] Synchronizing system time

by Camillo Bruni

On 2012-07-14, at 11:37, Denis Kudriashov wrote: > I think, you dont understand me. > > Getting current date and time not reflects system time changes. > Just start pharo then change your windows system time and execute > "DateAndTime now". > It will return wrong datetime. ah, ok, then that is clearly broken! yay Yet another substantial DateAndTime bug > So question: > how to reinitialize DateAndTime in such situation to get right system date > and time? most probably :) can you open a bug report with a reproducible description?

July 14, 2012

Re: [Pharo-project] Squeaksource moved

by Fabrizio Perin

Now you should be able to reach the files. As soon as you commit something could you please check if everything goes fine and if you can reach the uploaded file. Thanks, Fabrizio 2012/7/14 Fabrizio Perin <fabrizio.perin(a)gmail.com> > Investigating the problem. Let you know soon. > Fabrizio > 2012/7/13 Sean P. DeNigris <sean(a)clipperadams.com> > > >> Fabrizio Perin-3 wrote >> > >> > Today at 14 we moved squeaksource on a new machine >> >> http://www.squeaksource.com/phexample/Phexample-NikoSchwarz.57.mcz >> The package is listed in the versions, but trying to download -> 404 error >> >> Related to the move? >> >> -- >> View this message in context: >> http://forum.world.st/Squeaksource-moved-tp4639837p4639853.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

July 14, 2012

Re: [Pharo-project] Synchronizing system time

by Denis Kudriashov

I think, you dont understand me. Getting current date and time not reflects system time changes. Just start pharo then change your windows system time and execute "DateAndTime now". It will return wrong datetime. So question: how to reinitialize DateAndTime in such situation to get right system date and time? 2012/7/13 Camillo Bruni <camillobruni(a)gmail.com> > > On 2012-07-13, at 08:45, Denis Kudriashov wrote: > > > Hello, > > > > I try to implement system time synchronization with some server. > > And I found that when system OS time changed running pharo instance don't > > see that. > > I execute DateAndTime>>initializeOffsets but it not helps. > > > > Is it bug somewhere? > > Is it possible to reinitialize OS date and time from running pharo? > > Instances of DateAndTime directly store the seconds / nanoseconds for they > time. > If the underlying system time changes this is not reflected in the > existing instances... > > If you can get somehow the offset by which the time changed you can > manually loop > over all DateAndTime objects and replace the internal representations... > > DateAndTime allInstances do: [ :each| > each instVarNamed: #seconds put: each seconds + systemTimeChange ]. > > > I use WindowsXP > > > > Best regards, > > Denis > > >

July 14, 2012

Re: [Pharo-project] [update 2.0] #20209

by Mariano Martinez Peck

On Sat, Jul 14, 2012 at 9:31 AM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Yes, a set of layered compatibility packages is a solution, but a lot of > work to maintain. I guess. > >From my little experience with Fuel, it was the *easiest* way we found. We just put the overrides in the compatibility packages. No need to think how to be compatible. You can also do a lot of dirty hacks, like registering stuff in Smalltalk globals (for classes that were removed) or to create subclasses from the originals with the names you need, etc....What I mean is that I don't care how "beautiful" these compatibility packages are (as said, they are usually dirty). All I care is that they work and that they let me have the real beautiful code in trunk. > I was trying to avoid that. With FileSystem there was no way around it. > You mean the class renames? > > Thanks for the pointer. > > Sven > > On 14 Jul 2012, at 00:05, Mariano Martinez Peck wrote: > > > On Fri, Jul 13, 2012 at 10:47 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > > > On 13 Jul 2012, at 15:44, Marcus Denker wrote: > > > > > Issue 6356: some cleanups related to methods moved away from > SmalltalkImage (vm and os related) > > > http://code.google.com/p/pharo/issues/detail?id=6356 > > > > OK. but how can a poor library developer trying to write code that has > to remain compatible with 1.3 and 1.4 deal with this ? > > > > > > Last version of Fuel works from Pharo 1.1 to 2.0. What we do is to have > "Compatibility packages" which are usually some overrides in a few methods. > Fuel's "trunk" is CLEAN, as good as possible (no need of any backward > compatibility) and expected to work in latest Pharo while all the rest is > fixed in those overrides for those compatibility packages. For example, see > ConfigurationOfFuel: > > > > spec > > package: 'FuelCompatibilityForSqueak' with: [ spec > requires: #( 'FuelCompatibilityBeforePharo12' ) ]; > > package: 'FuelCompatibilityBeforePharo12' with: [ > spec requires: #( 'FuelCompatibilityBeforePharo13' ) ]; > > package: 'FuelCompatibilityBeforePharo13' with: [ > spec requires: #( 'FuelCompatibilityBeforePharo14' ) ]; > > package: 'FuelCompatibilityBeforePharo14' with: [ > spec requires: #( 'FuelCompatibilityBeforePharo20' ) ]; > > package: 'FuelCompatibilityBeforePharo20' with: [ > spec requires: #( 'Fuel' ) ]. > > > > > > The browse any of those packages to see what I mean. > > > > Maybe something like this can help you. > > > > Cheers > > > > Have a look at > > > > ZnUserAgentSettings class>>#platformDetails > > ^ self platform platformName, ' ', self platform > platformSubtype, ' ', self platform osVersion > > > > Now, this is a deprecated class in Zn as well, but rewriting > > > > self platform osVersion > > > > to > > > > self platform os version > > > > does not seem to give the same result in 1.4 > > > > Any suggestions ? > > > > Thx, > > > > Sven > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

July 14, 2012

Re: [Pharo-project] Squeaksource moved

by Fabrizio Perin

Investigating the problem. Let you know soon. Fabrizio 2012/7/13 Sean P. DeNigris <sean(a)clipperadams.com> > > Fabrizio Perin-3 wrote > > > > Today at 14 we moved squeaksource on a new machine > > http://www.squeaksource.com/phexample/Phexample-NikoSchwarz.57.mcz > The package is listed in the versions, but trying to download -> 404 error > > Related to the move? > > -- > View this message in context: > http://forum.world.st/Squeaksource-moved-tp4639837p4639853.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

July 14, 2012

Re: [Pharo-project] [update 2.0] #20209

by Sven Van Caekenberghe

On 14 Jul 2012, at 00:08, Marcus Denker wrote: > We could just add a good version of #version to SystemPlatform in 1.4. > Because what is called on 1.4 is #version of ClassDescription which is related to a > concept of class versions which seems to be some arcane stuff in need of cleanup. > > version > "Return the version number string of the platform we're running on" > "OSPlatform version" > > ^(Smalltalk vm getSystemAttribute: 1002) asString I'll have another look, it is not that important in the scope of Zinc (and it is used in a Zinc deprecated class anyway). Sven

July 14, 2012

Re: [Pharo-project] [update 2.0] #20209

by Sven Van Caekenberghe

Yes, a set of layered compatibility packages is a solution, but a lot of work to maintain. I guess. I was trying to avoid that. With FileSystem there was no way around it. Thanks for the pointer. Sven On 14 Jul 2012, at 00:05, Mariano Martinez Peck wrote: > On Fri, Jul 13, 2012 at 10:47 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 13 Jul 2012, at 15:44, Marcus Denker wrote: > > > Issue 6356: some cleanups related to methods moved away from SmalltalkImage (vm and os related) > > http://code.google.com/p/pharo/issues/detail?id=6356 > > OK. but how can a poor library developer trying to write code that has to remain compatible with 1.3 and 1.4 deal with this ? > > > Last version of Fuel works from Pharo 1.1 to 2.0. What we do is to have "Compatibility packages" which are usually some overrides in a few methods. Fuel's "trunk" is CLEAN, as good as possible (no need of any backward compatibility) and expected to work in latest Pharo while all the rest is fixed in those overrides for those compatibility packages. For example, see ConfigurationOfFuel: > > spec > package: 'FuelCompatibilityForSqueak' with: [ spec requires: #( 'FuelCompatibilityBeforePharo12' ) ]; > package: 'FuelCompatibilityBeforePharo12' with: [ spec requires: #( 'FuelCompatibilityBeforePharo13' ) ]; > package: 'FuelCompatibilityBeforePharo13' with: [ spec requires: #( 'FuelCompatibilityBeforePharo14' ) ]; > package: 'FuelCompatibilityBeforePharo14' with: [ spec requires: #( 'FuelCompatibilityBeforePharo20' ) ]; > package: 'FuelCompatibilityBeforePharo20' with: [ spec requires: #( 'Fuel' ) ]. > > > The browse any of those packages to see what I mean. > > Maybe something like this can help you. > > Cheers > > Have a look at > > ZnUserAgentSettings class>>#platformDetails > ^ self platform platformName, ' ', self platform platformSubtype, ' ', self platform osVersion > > Now, this is a deprecated class in Zn as well, but rewriting > > self platform osVersion > > to > > self platform os version > > does not seem to give the same result in 1.4 > > Any suggestions ? > > Thx, > > Sven > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 14, 2012