- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Looking for PhD students

by Natalia Tymchuk

Hello, Michele. I still want to get PhD position and I'm working on the idea you suggested me. Also I'm not sure if you know, but Voronyj diagram project won at Roassal Contest and I made the presentation about it on ESUG. In Cambridge I spoke with some people and got a few ideas, what to do next. You can look at the site: http://natalia.tymchuk.me/RTVoronyjDiagram/ the video for Contest: http://youtu.be/SlJptrlBbho the videos from presentation: https://www.youtube.com/watch?v=IUpndOXOsnY&list=UUO-vBhaKVZf0al-ISMMPvRw https://www.youtube.com/watch?v=XsF3YaC1m_w&list=UUO-vBhaKVZf0al-ISMMPvRw (I just realised, that I didn't mention you during the presentation. I'm really sorry about it, I was very nervous and didn't say the half from what I planed. But when I was speaking with people personaly I always said that it was your idea.) So, please let me know what do you think about me and my chances. Best regards, Natalia On Aug 27, 2014, at 10:40 AM, Michele Lanza <michele.lanza(a)usi.ch> wrote: > Dear all, > this is an informal call for PhD students. Iâm Michele Lanza, head of the REVEAL research group from the University of Lugano in Switzerland, active in Smalltalk since many years (16 to be precise). The group, which you might know from tools like CodeCity, SpyWare, Softwarenaut, SPO, etc. and its involvement in Moose and Pharo in general, currently features 4 PhD students and 1 postdoc. 3 PhD students program with and in Pharo, namely Yuriy Tymchuk, Roberto Minelli, and Tommaso dal Sasso, who recently attended ESUG. > Iâm looking for one or maybe even two PhD students. Topics with me are normally open and agreed upon by both sides, as long as itâs fun and relevant. I have some funky open topics. The only requirements are an open mind, good OO skills, the willingness to learn and to work hard. > > Drop me a line if youâre interested or know anyone whoâs interested. > > Thanks > > Michele > > BTW, I could say things about the nice climate in Lugano, the relatively good salary conditions, the generous available funding for traveling and hardware, etc. but if you come only for that you better stay away from me :-)

Aug. 27, 2014

Re: [Pharo-dev] athens wrapper for (Form-)Canvas

by Igor Stasenko

On 27 August 2014 09:42, stepharo <stepharo(a)free.fr> wrote: > Igor > > we should integrate TxText as soon as the new integration handle > configurations (normally next week). > So can you get prepared? > > I can make configuration with latest versions.. but that won't make things more 'prepared' in aspect that i am still did not took time to think about high-level API , so there's almost none at the moment.. and it is still a big question to me, how it should look like. i need a list of requirements from perspective of text editor widget, to at least know what API should be there.. because if people start using it without API, then it will be hard to do any changes later, once people integrate it into own projects.. i just don't want the complexity overflow us, we should keep things simple enough, hiding implementation details behind. We should discuss that.. because yeah.. you can create morph, place it on screen.. but that don't makes it easy or convenient to use. Stef > > > On 26/8/14 17:43, Igor Stasenko wrote: > > > > > On 26 August 2014 00:24, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> I tried an alternative approach for rendering Morphs on athens without >> implementing drawOnAthensCanvas for every morph: >> >> 13866 <https://pharo.fogbugz.com/default.asp?13866> >> AthensFormCanvasWrapper >> >> still struggling with the text rendering. Yet I am not sure what is the >> better approach. >> > > A new text model, which i am working on :) > > >> >> Nicolai >> > > > > -- > Best regards, > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

Aug. 27, 2014

Glorp Login>>#encodingStrategy

by Sven Van Caekenberghe

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. Sven

Aug. 27, 2014

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

by Nicolas Cellier

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

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

by Max Bareis

> > 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

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

by Sven Van Caekenberghe

Sure, I am not suggesting to add anything, I was just commenting on the fact that Date does indeed sometimes act a bit unexpected. On 27 Aug 2014, at 16:56, stepharo <stepharo(a)free.fr> wrote: > Sven > long time ago I was believing that this is important to have a nice and rich model for the core but on dates/calendars it is complex so > what I would do is to have a small and working code for Date/ and make sure that more complex model can be loaded by people. > > Stef > > On 27/8/14 12:02, Sven Van Caekenberghe wrote: >> 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