August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Change superclass programatically

by Martin McClure

On 08/27/2014 12:14 PM, Yuriy Tymchuk wrote: > Any ideas? https://stackoverflow.com/questions/25535202/change-superclass-programatica… > It looks like sending #superclass: to the class would work. Regards, -Martin

Aug. 27, 2014

Re: [Pharo-dev] Substitution of ' to " in TextEditor>>shiftEnclose

by Nicolas Cellier

Of course, similar code and change in Morphic, see bottom of change report http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160926.h… and follow links. This came after http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160923.h… But then, there were some complaints of English keyboard users... http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/160968.h… and then later http://forum.world.st/Re-squeak-dev-shift-enclose-broken-in-trunk-td4543316… I don't remember how the issue ended, or even if it properly ended... (That's where an issue tracker should shine, but Squeak one is not really used/maintained). 2014-08-27 17:27 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > I encountered this in Squeak too, because French keyboard is not better > than german one :( > > Nicolas Cellier uploaded a new version of ST80 to project The Trunk: > http://source.squeak.org/trunk/ST80-nice.136.mcz > > ==================== Summary ==================== > > Name: ST80-nice.136 > Author: nice > Time: 4 August 2011, 10:43:00.836 am > UUID: 6f8b2f4c-8c8c-48a8-ba32- > bb5b37d827d0 > Ancestors: ST80-ul.135 > > #shiftEnclose: is hardcoding the keyboard layout, which is not compatible > with foreign keyboards and modern VM, and prevents correct enclosing to > work. > > This version rather use a normal #enclose: > A (ParagraphEditor initialize) postscrip is necessary. > > =============== Diff against ST80-ul.135 =============== > > > > 2014-08-27 17:11 GMT+02:00 Max Bareis <max.bareis(a)me.com>: > > >> >> > >> > I am curious, because this substitution does not make any sense to >> > me. The keyCharacter is always the "real" character ( $( instead >> > of $9 ). Also it seems that this substitution reduces the keyboard >> > to the en-Layout, therefore breaks the separation of concerns. >> > >> > >> > >> > I hope this gets resolved, as it is really annoying with a german >> > Keyboard. >> > >> > And look at the issues: >> > 11436 <https://pharo.fogbugz.com/default.asp?11436> and >> > 4646 <https://pharo.fogbugz.com/default.asp?4646> >> > >> >Should the core team take action? >> > >> >Stef >> >> For me, there is no urgency. I sent it to the mailing list, because I used >> the wrong words for the issue search and didn't find any issue. As it is >> already on the issue list and I have a workaround (replacing the method in >> my download bash file for zeroconf) it is ok. >> >> Max >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Substitution-of-to-in-TextEditor-shiftEnclose-tp47750… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

Aug. 27, 2014

Change superclass programatically

by Yuriy Tymchuk

Any ideas? https://stackoverflow.com/questions/25535202/change-superclass-programatica…

Aug. 27, 2014

Re: [Pharo-dev] PharoLauncher on Windows not the latest version

by Ben Coman

Aug. 27, 2014

Re: [Pharo-dev] PharoLauncher on Windows not the latest version

by kilon alios

I will try your link tomorrow when I am back with windows pc, thank you On Wed, Aug 27, 2014 at 7:36 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Ok - then it could be that the jobs that produce those Platform specific > builds could be messed up (at least for windows). > > If you want the latest build - follow the CI link mentioned on Smalltalk > hub - which will end up on Jenkins, and the latex build is 886 - > https://ci.inria.fr/pharo-contribution/job/PharoLauncher/886/PHARO=30,VERSI… > > If you take that .image file you will have the absolute latest - which > does show Moose and Pharo 4. > > And I agree - we will leave Damien alone and when he gets back he said he > would look at my changes anyway - which should cause new platform builds. > > Tim > > On 27 Aug 2014, at 16:55, kilon alios <kilon.alios(a)gmail.com> wrote: > > No dont talk to Damien if he is on holiday , I prefer to respect people > free time / relaxation time. This can wait for when Damien will be back. > Both Damien and I frequent the irc channel so we will talk , its not a > problem. > > As I said in my original post I am downloading PharoLauncher from > Smalltalkhub links that can be located here > > http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher > > the link you posted is not contained in there , I used this > > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… > > and this > > > https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/last… > > As I said my problem is on Windows, on MacOS its fine . > > > On Wed, Aug 27, 2014 at 5:49 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hmmm that sounds strange (it could be I messed something up) - but did >> you get your zip file from: >> https://ci.inria.fr/pharo-contribution/job/PharoLauncher/885/PHARO=30,VERSI… >> ?? >> >> I just tested that one (but on OSX) and it shows my change as well as >> templates for Moose 5 and Pharo 4. >> >> Iâve just pushed another change (which would be 886), which also fixes a >> bug Stef mentioned (if underlying files change, it used to terminate >> instead of refreshing) - that should build shortly. >> >> However - the links on SmalltalkHub are still pointing to images from Jun >> (the Hudson jobs arenât triggered automatically it seems) - so I think you >> might be running something other than what you think you are running. >> >> Anyway - let me know what happens, and Iâll try and talk to Damien (who >> is on holiday) - and sort it out if Iâve broken it. >> >> Tim >> >> On 27 Aug 2014, at 15:16, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> I mean PharoLauncher cannot download Pharo 4 because it displays no such >> option. No Moose 5 , etc etc. Its also the old GUI. So this must be the >> latest version, I am not near my window pc now at work so I will try >> tomorrow the developer mode to see exactly which version of PharoLauncher >> it is. >> >> Are you on windows ? >> >> >> On Wed, Aug 27, 2014 at 5:07 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> What do you mean by Pharo 4 template? I just made a contribution >>> yesterday - watched it build the new zip file, and I just downloaded that >>> zip and I am seeing a âPharo 4.0 (beta)â template tree? >>> >>> Just to check you are using the latest version, if you right click on a >>> template and choose âCreate Imageâ - does it prefix the parent of the >>> template to the suggested name (e.g. Pharo 3.0-latest)? (this was the >>> change I made). >>> >>> It might be worth checking your settings as well (click on the icon >>> lower right) and check that you havenât accidentally unticked the Pharo 4.0 >>> repository. >>> >>> Tim >>> >>> On 27 Aug 2014, at 09:28, kilon alios <kilon.alios(a)gmail.com> wrote: >>> >>> I also downloaded the zip file it still does not give me the same >>> version as MacOSX, no Pharo 4 template >>> >>> >>> On Wed, Aug 27, 2014 at 11:04 AM, kilon alios <kilon.alios(a)gmail.com> >>> wrote: >>> >>>> I downloaded PharoLauncher from smalltalkhub for Windows and it appears >>>> is not the latest version for example it has no template for downloading >>>> Pharo 4. >>>> >>> >>> >>> >> >> > >

Aug. 27, 2014

Re: [Pharo-dev] PharoLauncher on Windows not the latest version

by Tim Mackinnon

Ok - then it could be that the jobs that produce those Platform specific builds could be messed up (at least for windows). If you want the latest build - follow the CI link mentioned on Smalltalk hub - which will end up on Jenkins, and the latex build is 886 - https://ci.inria.fr/pharo-contribution/job/PharoLauncher/886/PHARO=30,VERSI… If you take that .image file you will have the absolute latest - which does show Moose and Pharo 4. And I agree - we will leave Damien alone and when he gets back he said he would look at my changes anyway - which should cause new platform builds. Tim On 27 Aug 2014, at 16:55, kilon alios <kilon.alios(a)gmail.com> wrote: > No dont talk to Damien if he is on holiday , I prefer to respect people free time / relaxation time. This can wait for when Damien will be back. Both Damien and I frequent the irc channel so we will talk , its not a problem. > > As I said in my original post I am downloading PharoLauncher from Smalltalkhub links that can be located here > > http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher > > the link you posted is not contained in there , I used this > > https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… > > and this > > https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/last… > > As I said my problem is on Windows, on MacOS its fine . > > > On Wed, Aug 27, 2014 at 5:49 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hmmm that sounds strange (it could be I messed something up) - but did you get your zip file from: https://ci.inria.fr/pharo-contribution/job/PharoLauncher/885/PHARO=30,VERSI… ?? > > I just tested that one (but on OSX) and it shows my change as well as templates for Moose 5 and Pharo 4. > > Iâve just pushed another change (which would be 886), which also fixes a bug Stef mentioned (if underlying files change, it used to terminate instead of refreshing) - that should build shortly. > > However - the links on SmalltalkHub are still pointing to images from Jun (the Hudson jobs arenât triggered automatically it seems) - so I think you might be running something other than what you think you are running. > > Anyway - let me know what happens, and Iâll try and talk to Damien (who is on holiday) - and sort it out if Iâve broken it. > > Tim > > On 27 Aug 2014, at 15:16, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I mean PharoLauncher cannot download Pharo 4 because it displays no such option. No Moose 5 , etc etc. Its also the old GUI. So this must be the latest version, I am not near my window pc now at work so I will try tomorrow the developer mode to see exactly which version of PharoLauncher it is. >> >> Are you on windows ? >> >> >> On Wed, Aug 27, 2014 at 5:07 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> What do you mean by Pharo 4 template? I just made a contribution yesterday - watched it build the new zip file, and I just downloaded that zip and I am seeing a âPharo 4.0 (beta)â template tree? >> >> Just to check you are using the latest version, if you right click on a template and choose âCreate Imageâ - does it prefix the parent of the template to the suggested name (e.g. Pharo 3.0-latest)? (this was the change I made). >> >> It might be worth checking your settings as well (click on the icon lower right) and check that you havenât accidentally unticked the Pharo 4.0 repository. >> >> Tim >> >> On 27 Aug 2014, at 09:28, kilon alios <kilon.alios(a)gmail.com> wrote: >> >>> I also downloaded the zip file it still does not give me the same version as MacOSX, no Pharo 4 template >>> >>> >>> On Wed, Aug 27, 2014 at 11:04 AM, kilon alios <kilon.alios(a)gmail.com> wrote: >>> I downloaded PharoLauncher from smalltalkhub for Windows and it appears is not the latest version for example it has no template for downloading Pharo 4. >>> >> >> > >

Aug. 27, 2014

Re: [Pharo-dev] Glorp Login>>#encodingStrategy

by Esteban A. Maringolo

2014-08-27 12:38 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > It seems that Glorp Login>>#encodingStrategy is not used by the NativePostgresDriver yet it is required to set it to a non nil value to get things working. This feels like a hack or something unfinished. How so? PGConnection>>#clientEncoding: sets instance variables sqlStringConverter and receivingTextConverter, which are used to convert text back and forth from Pharo to the socket (see PGConnection>>#execute:) It is really convoluted, but I guess this has to do with the pass of time, and also with the half-backed (IMO) driver independence and dialect compatibility. Regards! Esteban A. Maringolo

Aug. 27, 2014

Re: [Pharo-dev] Fwd: A UTC based implementation of DateAndTime

by David T. Lewis

FYI, the UTC based DateAndTime that I did is not part of Squeak. http://wiki.squeak.org/squeak/6197 Date > Pharo's DateAndTime is not the same as Squeak's. > > We are properly UTC based/aware, see #secondsSinceMidnightUTC and > #julianDayNumberUTC. > > It is indeed perfectly possible to represent time using one number, but it > will not be a SmallInteger. And depending on precision is will be a very > large number. The split julian day number - seconds since midnight feels > quite logical and practical to me. > > But yes, the 'date' concept is often confusing and difficult to handle in > the light of timezones. To me, an old school, abstract Date object > year/month/day would make sense. But then again, there are so many > calendar systems, chronology is quite complicated. > > BasicJulianDate ? > > On 27 Aug 2014, at 01:10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> From >> http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4760319.html >> : >> >> >> David T. Lewis wrote >>> I have been working on a variation of class DateAndTime that replaces >>> its >>> instance variables (seconds offset jdn nanos) with two instance >>> variables, >>> utcMicroseconds to represent microseconds elapsed since the Posix >>> epoch, >>> and >>> localOffsetSeconds to represent the local time zone offset. When >>> instantiating >>> the time now, A single call primitiveUtcWithOffset is used to obtain >>> these >>> two values atomically as reported by the underlying platform. >>> >>> There are several advantages to this representation of DateAndTime, the >>> most >>> important of which is that its magnitude is unambiguous regardless of >>> daylight >>> savings transitions in local time zones. >>> >>> This is my attempt to address some historical baggage in Squeak. The VM >>> reports time related to the local time zone, and the image attempts to >>> convert to UTC (sometimes incorrectly). A UTC based representation >>> makes >>> the >>> implementation of time zone tables more straightforward (see for >>> example >>> the Olson time zone tables in TimeZoneDatabase on SqueakMap). >>> >>> I am attaching the source code as a SAR file that can be loaded into a >>> fully >>> updated Squeak trunk image. The conversion process is slow, so be >>> patient >>> if you load it. >>> >>> This can be run on either an intepreter VM or Cog, but if you use Cog, >>> please >>> use a version dated June 2013 or later (the VM in the Squeak 4.5 >>> all-in-one >>> is fine). >>> >>> I am also attaching a copy of LXTestDateAndTimePerformance, which can >>> be >>> used to compare the performance of some basic DateAndTime functions. >>> >>> Performance of the UTC based DateAndTime is generally favorable >>> compared >>> to >>> the original. Here is what I see on my system (smaller numbers are >>> better). >>> >>> LXTestDateAndTimePerformance test results using the original Squeak >>> DateAndTime >>> on an interpreter VM: >>> { >>> #testNow->10143 . >>> #testEquals->30986 . >>> #testGreaterThan->80199 . >>> #testLessThan->75912 . >>> #testPrintString->10429 . >>> #testStringAsDateAndTime->44657 >>> } >>> >>> LXTestDateAndTimePerformance test results using the new UTC based >>> DateAndTime >>> on an interpreter VM: >>> { >>> #testNow->6423 . >>> #testEquals->31625 . >>> #testGreaterThan->22999 . >>> #testLessThan->18514 . >>> #testPrintString->12502 . >>> #testStringAsDateAndTime->32912 >>> } >>> >>> (CC to Brent Pinkney, author of the excellent Squeak Chronology >>> package) >>> >>> Dave >>> >>> >>> >>> >>> >>> UtcDateAndTime-dtl.sar (40K) >>> <http://forum.world.st/attachment/4760319/0/UtcDateAndTime-dtl.sar> >>> LXTestDateAndTimePerformance.st (2K) >>> <http://forum.world.st/attachment/4760319/1/LXTestDateAndTimePerformance.st> >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Fwd-A-UTC-based-implementation-of-DateAndTime-tp47749… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> > >

Aug. 27, 2014

Re: [Pharo-dev] PharoLauncher on Windows not the latest version

by kilon alios

No dont talk to Damien if he is on holiday , I prefer to respect people free time / relaxation time. This can wait for when Damien will be back. Both Damien and I frequent the irc channel so we will talk , its not a problem. As I said in my original post I am downloading PharoLauncher from Smalltalkhub links that can be located here http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher the link you posted is not contained in there , I used this https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/lastSu… and this https://ci.inria.fr/pharo-contribution/job/PharoLauncherFinalUserImage/last… As I said my problem is on Windows, on MacOS its fine . On Wed, Aug 27, 2014 at 5:49 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Hmmm that sounds strange (it could be I messed something up) - but did you > get your zip file from: > https://ci.inria.fr/pharo-contribution/job/PharoLauncher/885/PHARO=30,VERSI… > ?? > > I just tested that one (but on OSX) and it shows my change as well as > templates for Moose 5 and Pharo 4. > > Iâve just pushed another change (which would be 886), which also fixes a > bug Stef mentioned (if underlying files change, it used to terminate > instead of refreshing) - that should build shortly. > > However - the links on SmalltalkHub are still pointing to images from Jun > (the Hudson jobs arenât triggered automatically it seems) - so I think you > might be running something other than what you think you are running. > > Anyway - let me know what happens, and Iâll try and talk to Damien (who is > on holiday) - and sort it out if Iâve broken it. > > Tim > > On 27 Aug 2014, at 15:16, kilon alios <kilon.alios(a)gmail.com> wrote: > > I mean PharoLauncher cannot download Pharo 4 because it displays no such > option. No Moose 5 , etc etc. Its also the old GUI. So this must be the > latest version, I am not near my window pc now at work so I will try > tomorrow the developer mode to see exactly which version of PharoLauncher > it is. > > Are you on windows ? > > > On Wed, Aug 27, 2014 at 5:07 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> What do you mean by Pharo 4 template? I just made a contribution >> yesterday - watched it build the new zip file, and I just downloaded that >> zip and I am seeing a âPharo 4.0 (beta)â template tree? >> >> Just to check you are using the latest version, if you right click on a >> template and choose âCreate Imageâ - does it prefix the parent of the >> template to the suggested name (e.g. Pharo 3.0-latest)? (this was the >> change I made). >> >> It might be worth checking your settings as well (click on the icon lower >> right) and check that you havenât accidentally unticked the Pharo 4.0 >> repository. >> >> Tim >> >> On 27 Aug 2014, at 09:28, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> I also downloaded the zip file it still does not give me the same version >> as MacOSX, no Pharo 4 template >> >> >> On Wed, Aug 27, 2014 at 11:04 AM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> I downloaded PharoLauncher from smalltalkhub for Windows and it appears >>> is not the latest version for example it has no template for downloading >>> Pharo 4. >>> >> >> >> > >

Aug. 27, 2014

Opal, custom compilers and class-side methods

by Camille Teruel

Hi all, With Opal, if you want to customize how methods are compiled into a class you can override #compilerClass on class-side: MyClass class>>#compilerClass ^ MySpecialCompiler However this custom compiler is not taken into account when compiling methods on the class-side: MyClass class compilerClass ---> OpalCompiler I was expecting to have the same compiler class for the metaclass. The consequence is that right now there is no way to specialize how methods are compiled in *one* metaclass. Is it on purpose or is it a bug? Also is there cases where one wants instance-side methods and class-side methods to be compiled with different compiler classes? My rough guess is that in most cases you want the same compiler class, but I don't fell confortable forcing that. So I propose to add a method #classSideCompilerClass: Class>>#classSideCompilerClass ^ self compilerClass Then compilerClass can be implemented for metaclasses: Metaclass>>#compilerClass ^ self instanceSide classSideCompilerClass Likewise, if I override compilerClass, it is taken into account for both instance-side and class-side methods but I can still say that I want a different compiler for class-side methods by overriding classSideCompilerClass. Tell me what you think about it and if you're ok, I open a bug entry with the slice. Cheers, Camille

Aug. 27, 2014