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

Re: [Pharo-dev] Run time checking with design by contract assertions

by stepharo

Le 2/3/16 20:00, Alain Rastoul a Ã©crit : > I have no pretention to do a perfect dbc implmentation, I just want to > see at first stage if a simple implementation based on the MetaLink > can work. Yes incremental and working is better than excellent and not finished.

March 15, 2016

Re: [Pharo-dev] TextConverter is broken

by stepharo

Thanks you all and I love the bug entry. Hi nicolas I understand your point but you see nicolas we are not sprinting blindly. We are the guys that pushed SUnit Tests in Squeak back then and in Pharo as well. We are pushing for Quality Rules and a lot more. Now we are doing a lot of things because the world is moving and we have a dream to make comes true :) And you would commit to Pharo would help us too because we have a long list of great changes. - Epicea - Bootstrap - Bloc - Xtreams - Stef Le 4/3/16 11:28, Max Leske a Ã©crit : > https://pharo.fogbugz.com/f/cases/17751/Remove-TextConverter > > >> On 03 Mar 2016, at 09:32, Max Leske <maxleske(a)gmail.com> wrote: >> >> Thank you everyone for the explanations. >> >> How would you feel about opening an issue for Pharo 6 to remove >> TextConverter? >> >>> On 03 Mar 2016, at 01:04, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com >>> <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >>> >>> In other words Max, if you correctly invoke >>> >>> MacRomanTextConverter initializeLatin1MapAndEncodings. >>> >>> Then the old converter retrieves a good health. >>> Now that you know that, you can remove the old converters and keep >>> Zn modernized ones ;) >> >> That does indeed fix the problem. >> >>> >>> 2016-03-03 0:56 GMT+01:00 Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com >>> <mailto:nicolas.cellier.aka.nice@gmail.com>>: >>> >>> >>> >>> 2016-03-02 23:16 GMT+01:00 Henrik Sperre Johansen >>> <henrik.s.johansen(a)veloxit.no >>> <mailto:henrik.s.johansen@veloxit.no>>: >>> >>> Not sure I'd say Squeak's (5.0 at least) MacRoman conversion >>> is free of bugs >>> either, at least the "legacy" ByteTextConverter subclass in >>> Pharo passes the >>> following: >>> >>> "U+0152, Latin capital ligature OE is codepoint 16rCE in >>> mac-roman" >>> ((Character value: 16r0152) asString convertToEncoding: >>> 'mac-roman') first >>> charCode = 16rCE. >>> >>> "Codepoint 170 in MacRoman is TM sign, U+2122" >>> ((Character value: 170) asString convertFromEncoding: >>> 'mac-roman') first >>> charCode = 16r2122. >>> >>> Cheers, >>> Henry >>> >>> >>> >>> Yes, you're right, it's because squeak tables did and still use >>> CP1252 instead of ISO8859-L1 and thus do not match unicode. That >>> might have made sense when porting from mac to windows while >>> keeping ByteString, but at least since the switch to unicode >>> that's bogus. I guess it's still here because some in image >>> fonts would support cp1252 but I am too tired to check it now... >>> >>> My mistake is that character unicode 216 -> MacRoman was already >>> false in Pharo 1.1. >>> It was false because Pharo picked a a bogus table manually >>> crafted from the internet pages (from Sophie project?) >>> >>> Then Sven did correct the table by automagically decoding the url... >>> But this didn't correct anything because the >>> initializeLatin1MapAndEncodings was never invoked (it was >>> missing already in Pharo 1.1). >>> Unfortunately, those maps are a speed-up cache and will mask the >>> correction of table if not updated. >>> >>> In Squeak, initializeLatin1MapAndEncodings was called from class >>> side initialization right from the beginning, but this was >>> forgotten during the port to Pharo, that would be interesting to >>> know why... >>> >>> Ah yes, lazy initialization made it work without the need for >>> class initialization, but that was a one shot gun, not robust to >>> further table changes, that's the drawback of being lazy. >>> >>> So, most probably code was too complex and this is enough to >>> explain the mistakes. >>> Why was it too complex? >>> Because it was an optimization for speed (fast scanning of bytes >>> NOT NEEDING ANY conversion). >>> And the initialization was too much convoluted because it was >>> reusing convoluted multilngual API. >>> My feeling is that it's an effect of the "least possible change >>> that could possibly extend functionality". >>> >>> For me, it's never enough to say "old converters were broken". >>> There's allways to learn from one mistake and that's why I'm asking. >>> My feeling is that Pharo guys allways sprint and never look behind. >>> This is at the risk of repeating some mistake... >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/TextConverter-is-broken-tp4882039p4882095.html >>> Sent from the Pharo Smalltalk Developers mailing list >>> archive at Nabble.com <http://nabble.com/>. >>> >>> >>> >> >

March 15, 2016

Re: [Pharo-dev] Loading an image crashes the VM

by Max Leske

I should have looked at the attachmentâ¦ What youâre seeing is a problem with UFFI, Esteban is trying to hunt down the cause. For some reason the font loading mechanism uses an FFI call that doesnât always do what itâs supposed to. Usually this will lead to a playground or browser displaying a red âsquare for deathâ after boot but Iâve also seen segfaults myself. This (very likely) has nothing to do with image size, as I suggested earlier. Unfortunately, I donât think there is a fix at the moment other than trying save a new copy of the image. Cheers, Max > On 15 Mar 2016, at 01:54, Ben Coman <btc(a)openInWorld.com> wrote: > > On Tue, Mar 15, 2016 at 1:25 AM, Jan KurÅ¡ <kurs(a)inf.unibe.ch> wrote: >> Hi, >> >> I am trying to open an image I saved a few days ago and I am getting this >> message (the whole log is attached): >> >> stack page bytes 4096 available headroom 2788 minimum unused headroom 3020 >> >> (Segmentation fault) >> >> Anyone experiencing something similar? I am running the latest pharo5 VM on >> Linux. >> >> Cheers, >> Jan > > Something similar happened to me for the first time last night, about > three times in quick succession. Seemed to be when I started an Image > from a shell and later killed it with control-C. Incidentally, these > was with a recent Tracker image only an hour old for me, which had > locked while I was doing risky changes to DelayScheduler, but I was > surprised that it affected the Image on disk. I was doing temporary > checkpoint saves just prior to Accepting risky code changes. Then upon > restart I got the error. But I could not reliably reproduce the > problem. > > Certainly it was not a large Image. > > VM: http://files.pharo.org/vm/pharo-spur32/linux/463.zip > Image: https://ci.inria.fr/pharo/view/5.0-Analysis/job/Pharo-5.0-Issue-Tracker-Ima… > Platform: Debian 8 Jessie 32-bit > > cheers -ben >

March 15, 2016

Re: [Pharo-dev] Loading an image crashes the VM

by Ben Coman

On Tue, Mar 15, 2016 at 1:25 AM, Jan KurÅ¡ <kurs(a)inf.unibe.ch> wrote: > Hi, > > I am trying to open an image I saved a few days ago and I am getting this > message (the whole log is attached): > > stack page bytes 4096 available headroom 2788 minimum unused headroom 3020 > > (Segmentation fault) > > Anyone experiencing something similar? I am running the latest pharo5 VM on > Linux. > > Cheers, > Jan Something similar happened to me for the first time last night, about three times in quick succession. Seemed to be when I started an Image from a shell and later killed it with control-C. Incidentally, these was with a recent Tracker image only an hour old for me, which had locked while I was doing risky changes to DelayScheduler, but I was surprised that it affected the Image on disk. I was doing temporary checkpoint saves just prior to Accepting risky code changes. Then upon restart I got the error. But I could not reliably reproduce the problem. Certainly it was not a large Image. VM: http://files.pharo.org/vm/pharo-spur32/linux/463.zip Image: https://ci.inria.fr/pharo/view/5.0-Analysis/job/Pharo-5.0-Issue-Tracker-Ima… Platform: Debian 8 Jessie 32-bit cheers -ben

March 15, 2016

Re: [Pharo-dev] Loading an image crashes the VM

by Max Leske

How large is your image? Thereâs a bug in the VM where it canât open large images. > On 14 Mar 2016, at 18:25, Jan KurÅ¡ <kurs(a)inf.unibe.ch> wrote: > > Hi, > > I am trying to open an image I saved a few days ago and I am getting this message (the whole log is attached): > > stack page bytes 4096 available headroom 2788 minimum unused headroom 3020 > > (Segmentation fault) > > Anyone experiencing something similar? I am running the latest pharo5 VM on Linux. > > Cheers, > Jan > <log.txt>

March 14, 2016

Re: [Pharo-dev] Status of pharo Android and Pharo ios ?

by stepharo

Me too. I really hope that the spur migration (including just building another FFI) will not burn esteban. We really got burned by that. Stef Le 14/3/16 18:12, jannik laval a Ã©crit : > Thank you Stef, > > I hope someone could work again on it. > > Cheers, > Jannik > > 2016-03-12 11:16 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > > Le 12/3/16 09:44, jannik laval a Ã©crit : > > Hi pharoers, > > What is the status of pharo for android and pharo for iOS ? > > > For android not much changes. I was pushing but nothing came out. > I'm sorry. > > Stef > > > Thank you for the answer > > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en > SystÃ¨me d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > > > > > > > -- > ~~Jannik Laval~~ > Enseignant-chercheur > Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me > d'Information > IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re > laboratoire DISP > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info

March 14, 2016

Re: [Pharo-dev] TimeZoneDatabase - are we using this?

by stepharo

I should say that I love such class comments Keep your great work sven. Stef Le 14/3/16 10:14, Sven Van Caekenberghe a Ã©crit : > Yes, the ZTimestamp project has that. > > Here is the class comment of ZTimezone > > === > I am ZTimezone, representing the timezone information in the standard Olsen database. > > http://en.wikipedia.org/wiki/Tz_database > > Usage > > You reference timezones by their ID. The list of supported identifiers is accessible using > > ZTimezone timezoneIdentifiers. > > To access a timezone do > > ZTimezone id: 'Europe/Brussels'. > > The necessary information will be loaded, parsed and cached from a binary file of the zoneinfo database (see also man tzfile). This should work automagically on Mac OS X and Unix, on Windows you have to download the necessary files and specify their location > > ZTimezone zoneInfoLocation: FileLocator C / 'foo' / 'bar' / 'zoneinfo'. > > Once you get a handle on a timezone, the main operation is to query the sub timezone that is applicable at a certain point in time > > (ZTimezone id: 'Europe/Brussels') subzoneForTimestamp: ZTimestamp now. > > The ZSubTimezone instance returned contains information like the UTC offset. Since you'll probably only be interested in that aspect there is a convenience method > > (ZTimezone id: 'Europe/Brussels') offsetForTimestamp: DateAndTime now. > > The flow is that for every GMT timestamp, you get the concrete offset to use for a specific timezone. Note that this is not a constant, it depends on the time periode the timestamp falls in. > > The are 2 more convenience methods to quickly convert between GTM and local wall time > > (ZTimezone id: #'Europe/Brussels') gmtToLocal: ZTimestamp now. > (ZTimezone id: #'Europe/Brussels') localToGmt: DateAndTime now. > > Also note the zoneTab and the timezones are cached in the image. When the TZ database changes, it might be necessary to either call #cleanUp or #reloadAll. When moving images between machines, either all info should be loaded and cached, or it might be necessary to use #zoneInfoLocation: again. > > Implementation > > A chronological array of transition points in unix time specifies which sub zone is active from that point on to the next. > > Limitations > > The format 2 data following the format 1 data is not read as it is a duplicate. Leap seconds, the standard/wall indicators and the UTC/local indicators are currently ignored, but their information is read and stored. > === > > Sven > >> On 14 Mar 2016, at 10:09, phil(a)highoctane.be wrote: >> >> I saw TimeZoneDatabase on SS3 (and updated this month) >> >> Are we using this in Pharo in any way? Seems like a must have. >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/TimeZoneDatabase' >> user: '<youruser>' >> password: '' >> >> Phil > >

March 14, 2016

Re: [Pharo-dev] TimeZoneDatabase - are we using this?

by Paul DeBruicker

I just added a DateTime class as a subclass of DateAndTimeto that project today, which retains the time zone name with the instance so times in the future can, as needed have their offsets changed to reflect new legislative decisions. It works in Pharo 4 on Mac/Linux. Not on Windows at the moment. AFAIK it hasn't been loaded/tested in Pharo 5 yet. Paul philippeback wrote > I saw TimeZoneDatabase on SS3 (and updated this month) > > Are we using this in Pharo in any way? Seems like a must have. > > MCHttpRepository > > location: 'http://www.squeaksource.com/TimeZoneDatabase' > user: ' > <youruser> > ' > > password: '' > > > Phil -- View this message in context: http://forum.world.st/TimeZoneDatabase-are-we-using-this-tp4884404p4884494.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 14, 2016

Loading an image crashes the VM

by Jan KurÅ¡

Hi, I am trying to open an image I saved a few days ago and I am getting this message (the whole log is attached): stack page bytes 4096 available headroom 2788 minimum unused headroom 3020 (Segmentation fault) Anyone experiencing something similar? I am running the latest pharo5 VM on Linux. Cheers, Jan

March 14, 2016

Re: [Pharo-dev] Status of pharo Android and Pharo ios ?

by jannik laval

Thank you Stef, I hope someone could work again on it. Cheers, Jannik 2016-03-12 11:16 GMT+01:00 stepharo <stepharo(a)free.fr>: > > > Le 12/3/16 09:44, jannik laval a Ã©crit : > >> Hi pharoers, >> >> What is the status of pharo for android and pharo for iOS ? >> > > For android not much changes. I was pushing but nothing came out. > I'm sorry. > > Stef > > >> Thank you for the answer >> >> -- >> ~~Jannik Laval~~ >> Enseignant-chercheur >> Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me >> d'Information >> IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re >> laboratoire DISP >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://www.approchealpes.info >> > > > -- ~~Jannik Laval~~ Enseignant-chercheur Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me d'Information IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re laboratoire DISP http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

March 14, 2016