- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Are these changes good enough

by Sergio Fedi

Yes In the site it says that it is preferable via surface mail. But a fax is good enough. Does this still hold true? (if so, I would rather send it via fax, or scanned, or another medium)

May 1, 2015

Re: [Pharo-dev] build pharo vm on windows (old mingw package)

by phil＠highoctane.be

https://www.dropbox.com/s/e5ws36rxo2z19lf/pharo-vm.zip?dl=0 On Fri, May 1, 2015 at 9:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-30 11:33 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> arenât you able to install an older version of gcc in your newer version >> of mingw? >> > > hm, downgrading the compiler was suprisingly easy. But I have still the > same error. > This is the gcc version information: > > Using built-in specs. > COLLECT_GCC=c:\MinGW\bin\gcc.exe > > COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe > Target: mingw32 > Configured with: ../gcc-4.6.2/configure > --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions > --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry > --enable-libstdcxx-debug --enable-version-specific-runtime-libs > --build=mingw32 --prefix=/mingw > Thread model: win32 > gcc version 4.6.2 (GCC) > > > Anyone knows what could be the problem ? Stacktrace from the crash, this > happens > directly after the start: > > #0 0x772359dd in ntdll!RtlpNtMakeTemporaryKey () > from C:\Windows\system32\ntdll.dll > #1 0x77201d8f in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll > #2 0x77236a37 in ntdll!RtlpNtMakeTemporaryKey () > from C:\Windows\system32\ntdll.dll > #3 0x771fa3ef in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll > #4 0x771c6766 in wcsnicmp () from C:\Windows\system32\ntdll.dll > #5 0x76cdc484 in KERNEL32!HeapFree () from > C:\Windows\system32\kernel32.dll > #6 0x6c24c4d7 in free () from C:\Windows\system32\crtdll.dll > #7 0x00850000 in ?? () > #8 0x00542065 in glob_match () > #9 0x00542604 in __mingw_glob () > #10 0x00540f17 in _setargv () > #11 0x004011ca in __mingw_CRTStartup () > #12 0x004012d5 in WinMainCRTStartup () > > > > > > nicolai > > > > >> I do not have time right now to update the build into a new compiler, >> sorry (also, that is not always trivial/desired, he) >> >> Esteban >> >> > On 30 Apr 2015, at 08:38, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > >> > I managed to trash my mingw build environment >> > -> uninstalled /removed mingw/mingsys >> > -> reinstall from current mingw-installer >> > -> bad idea >> > >> > I can build a pharo windows vm but it immediately crashes on startup. I >> suspect >> > some changes between gcc 4.6 (old environment) gcc 4.8 (new >> environment). >> > (I think there are some changes related to file globbing (I managed to >> get >> > the vm somehow working to not crash on startup but on shutdown instead >> - with >> > _CRT_glob = 0. And gcc-4.8 uses dfferent (dwarf vs. sjlj ) exception >> handling, don't know if this is >> > related). >> > >> > I tried to find a ming-installer for the old version but could not find >> anything and >> > I tried to manually setup a ming installation from the old packages >> (dozen of packages >> > for mingw / core-utils / bintutils /msys from different places (no >> fun)). >> > >> > 1) did anyone get a windows vm from mingws current version (with gcc >> 4.8) working? >> > >> > 2) can someone package/zip and upload an old mingw installation (maybe >> that one that >> > is used on the build server? >> > >> > >> > regards >> > nicolai >> >> >

May 1, 2015

Re: [Pharo-dev] build pharo vm on windows (old mingw package)

by Nicolai Hess

2015-05-01 23:05 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Did you tried this ? > > https://github.com/pharo-project/pharo-vm/blob/master/README-Win32.md > Yes, I already worked with mingw and setup a build environment (at that time it was with gcc 4.6.x) All went well and I build working pharo vms, but recently I accidently trashed this environment. Now, the new environment from the current mingw-installer, produces a vm that crashes at start up. > (I wrote that thing a while ago). > > > http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/m… > was where I got the env from. > > I've got a PharoVM built with gcc 4.8.1 > > Uploading the thing in dropbox. > > Will send a link when done. > > Phil > > > On Fri, May 1, 2015 at 9:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-04-30 11:33 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> arenât you able to install an older version of gcc in your newer version >>> of mingw? >>> >> >> hm, downgrading the compiler was suprisingly easy. But I have still the >> same error. >> This is the gcc version information: >> >> Using built-in specs. >> COLLECT_GCC=c:\MinGW\bin\gcc.exe >> >> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe >> Target: mingw32 >> Configured with: ../gcc-4.6.2/configure >> --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions >> --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry >> --enable-libstdcxx-debug --enable-version-specific-runtime-libs >> --build=mingw32 --prefix=/mingw >> Thread model: win32 >> gcc version 4.6.2 (GCC) >> >> >> Anyone knows what could be the problem ? Stacktrace from the crash, this >> happens >> directly after the start: >> >> #0 0x772359dd in ntdll!RtlpNtMakeTemporaryKey () >> from C:\Windows\system32\ntdll.dll >> #1 0x77201d8f in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll >> #2 0x77236a37 in ntdll!RtlpNtMakeTemporaryKey () >> from C:\Windows\system32\ntdll.dll >> #3 0x771fa3ef in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll >> #4 0x771c6766 in wcsnicmp () from C:\Windows\system32\ntdll.dll >> #5 0x76cdc484 in KERNEL32!HeapFree () from >> C:\Windows\system32\kernel32.dll >> #6 0x6c24c4d7 in free () from C:\Windows\system32\crtdll.dll >> #7 0x00850000 in ?? () >> #8 0x00542065 in glob_match () >> #9 0x00542604 in __mingw_glob () >> #10 0x00540f17 in _setargv () >> #11 0x004011ca in __mingw_CRTStartup () >> #12 0x004012d5 in WinMainCRTStartup () >> >> >> >> >> >> nicolai >> >> >> >> >>> I do not have time right now to update the build into a new compiler, >>> sorry (also, that is not always trivial/desired, he) >>> >>> Esteban >>> >>> > On 30 Apr 2015, at 08:38, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> > >>> > I managed to trash my mingw build environment >>> > -> uninstalled /removed mingw/mingsys >>> > -> reinstall from current mingw-installer >>> > -> bad idea >>> > >>> > I can build a pharo windows vm but it immediately crashes on startup. >>> I suspect >>> > some changes between gcc 4.6 (old environment) gcc 4.8 (new >>> environment). >>> > (I think there are some changes related to file globbing (I managed to >>> get >>> > the vm somehow working to not crash on startup but on shutdown instead >>> - with >>> > _CRT_glob = 0. And gcc-4.8 uses dfferent (dwarf vs. sjlj ) exception >>> handling, don't know if this is >>> > related). >>> > >>> > I tried to find a ming-installer for the old version but could not >>> find anything and >>> > I tried to manually setup a ming installation from the old packages >>> (dozen of packages >>> > for mingw / core-utils / bintutils /msys from different places (no >>> fun)). >>> > >>> > 1) did anyone get a windows vm from mingws current version (with gcc >>> 4.8) working? >>> > >>> > 2) can someone package/zip and upload an old mingw installation (maybe >>> that one that >>> > is used on the build server? >>> > >>> > >>> > regards >>> > nicolai >>> >>> >> >

May 1, 2015

Re: [Pharo-dev] build pharo vm on windows (old mingw package)

by phil＠highoctane.be

Did you tried this ? https://github.com/pharo-project/pharo-vm/blob/master/README-Win32.md (I wrote that thing a while ago). http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/m… was where I got the env from. I've got a PharoVM built with gcc 4.8.1 Uploading the thing in dropbox. Will send a link when done. Phil On Fri, May 1, 2015 at 9:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-04-30 11:33 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> arenât you able to install an older version of gcc in your newer version >> of mingw? >> > > hm, downgrading the compiler was suprisingly easy. But I have still the > same error. > This is the gcc version information: > > Using built-in specs. > COLLECT_GCC=c:\MinGW\bin\gcc.exe > > COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe > Target: mingw32 > Configured with: ../gcc-4.6.2/configure > --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions > --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry > --enable-libstdcxx-debug --enable-version-specific-runtime-libs > --build=mingw32 --prefix=/mingw > Thread model: win32 > gcc version 4.6.2 (GCC) > > > Anyone knows what could be the problem ? Stacktrace from the crash, this > happens > directly after the start: > > #0 0x772359dd in ntdll!RtlpNtMakeTemporaryKey () > from C:\Windows\system32\ntdll.dll > #1 0x77201d8f in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll > #2 0x77236a37 in ntdll!RtlpNtMakeTemporaryKey () > from C:\Windows\system32\ntdll.dll > #3 0x771fa3ef in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll > #4 0x771c6766 in wcsnicmp () from C:\Windows\system32\ntdll.dll > #5 0x76cdc484 in KERNEL32!HeapFree () from > C:\Windows\system32\kernel32.dll > #6 0x6c24c4d7 in free () from C:\Windows\system32\crtdll.dll > #7 0x00850000 in ?? () > #8 0x00542065 in glob_match () > #9 0x00542604 in __mingw_glob () > #10 0x00540f17 in _setargv () > #11 0x004011ca in __mingw_CRTStartup () > #12 0x004012d5 in WinMainCRTStartup () > > > > > > nicolai > > > > >> I do not have time right now to update the build into a new compiler, >> sorry (also, that is not always trivial/desired, he) >> >> Esteban >> >> > On 30 Apr 2015, at 08:38, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > >> > I managed to trash my mingw build environment >> > -> uninstalled /removed mingw/mingsys >> > -> reinstall from current mingw-installer >> > -> bad idea >> > >> > I can build a pharo windows vm but it immediately crashes on startup. I >> suspect >> > some changes between gcc 4.6 (old environment) gcc 4.8 (new >> environment). >> > (I think there are some changes related to file globbing (I managed to >> get >> > the vm somehow working to not crash on startup but on shutdown instead >> - with >> > _CRT_glob = 0. And gcc-4.8 uses dfferent (dwarf vs. sjlj ) exception >> handling, don't know if this is >> > related). >> > >> > I tried to find a ming-installer for the old version but could not find >> anything and >> > I tried to manually setup a ming installation from the old packages >> (dozen of packages >> > for mingw / core-utils / bintutils /msys from different places (no >> fun)). >> > >> > 1) did anyone get a windows vm from mingws current version (with gcc >> 4.8) working? >> > >> > 2) can someone package/zip and upload an old mingw installation (maybe >> that one that >> > is used on the build server? >> > >> > >> > regards >> > nicolai >> >> >

May 1, 2015

Re: [Pharo-dev] build pharo vm on windows (old mingw package)

by Nicolai Hess

2015-04-30 11:33 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > arenât you able to install an older version of gcc in your newer version > of mingw? > hm, downgrading the compiler was suprisingly easy. But I have still the same error. This is the gcc version information: Using built-in specs. COLLECT_GCC=c:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.6.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.6.2 (GCC) Anyone knows what could be the problem ? Stacktrace from the crash, this happens directly after the start: #0 0x772359dd in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\system32\ntdll.dll #1 0x77201d8f in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll #2 0x77236a37 in ntdll!RtlpNtMakeTemporaryKey () from C:\Windows\system32\ntdll.dll #3 0x771fa3ef in ntdll!EtwSetMark () from C:\Windows\system32\ntdll.dll #4 0x771c6766 in wcsnicmp () from C:\Windows\system32\ntdll.dll #5 0x76cdc484 in KERNEL32!HeapFree () from C:\Windows\system32\kernel32.dll #6 0x6c24c4d7 in free () from C:\Windows\system32\crtdll.dll #7 0x00850000 in ?? () #8 0x00542065 in glob_match () #9 0x00542604 in __mingw_glob () #10 0x00540f17 in _setargv () #11 0x004011ca in __mingw_CRTStartup () #12 0x004012d5 in WinMainCRTStartup () nicolai > I do not have time right now to update the build into a new compiler, > sorry (also, that is not always trivial/desired, he) > > Esteban > > > On 30 Apr 2015, at 08:38, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > I managed to trash my mingw build environment > > -> uninstalled /removed mingw/mingsys > > -> reinstall from current mingw-installer > > -> bad idea > > > > I can build a pharo windows vm but it immediately crashes on startup. I > suspect > > some changes between gcc 4.6 (old environment) gcc 4.8 (new environment). > > (I think there are some changes related to file globbing (I managed to > get > > the vm somehow working to not crash on startup but on shutdown instead - > with > > _CRT_glob = 0. And gcc-4.8 uses dfferent (dwarf vs. sjlj ) exception > handling, don't know if this is > > related). > > > > I tried to find a ming-installer for the old version but could not find > anything and > > I tried to manually setup a ming installation from the old packages > (dozen of packages > > for mingw / core-utils / bintutils /msys from different places (no fun)). > > > > 1) did anyone get a windows vm from mingws current version (with gcc > 4.8) working? > > > > 2) can someone package/zip and upload an old mingw installation (maybe > that one that > > is used on the build server? > > > > > > regards > > nicolai > >

May 1, 2015

Re: [Pharo-dev] [Pharo-users] Fuel version

by Max Leske

> On 01 May 2015, at 18:14, Johannes Rasche Kreuzberg <Johannes(a)Rasche-Kreuzberg.de> wrote: > > Max, > > well the ConfigurationOfFuel in Pharo 3 does not know Fuel 1.9.4 > > and in Pharo 4 there is no ConfigurationOfFuel > neither in the image (ConfigBrowser) > nor on http://smalltalkhub.mc/Pharo/MetaRepoForPharo40/main <http://smalltalkhub.mc/Pharo/MetaRepoForPharo40/main> Fuel is part of Pharo, so you wonât find a configuration in the meta repository. Thatâs why I posted the Gofer code to get the latest configuration with version 1.9.4: Gofer it url: 'http://smalltalkhub.com/mc/Pharo/Fuel/main'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: â1.9.4') load. (See http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Installation) We have builds that make sure that version is loadable in Pharo 3 and 4, so it should work. Otherwise, please hit me up again. Cheers, Max > > what's up? do I oversee somthing relevant ? > > Johannes > > Am 30.04.15 um 15:04 schrieb Max Leske: >> >>> On 30 Apr 2015, at 14:40, Mariano Martinez Peck <marianopeck(a)gmail.com >>> <mailto:marianopeck@gmail.com>> wrote: >>> >>> Johannes, >>> >>> The simples approach is that you materialize your object in 3.0, then >>> load the same version as fuel from pharo 4.0 and then serialize again >>> in 3.0. >> >> That should work without problems now. Just be aware that some things >> have changed dramatically (e.g. MethodContext no longer exists, instead >> there is now Context). For most of the objects however, migration should >> work fine when you use the Pharo 4 version (1.9.4) in Pharo 3. >> >>> After that, you can materialize in 4.0. >>> The other alternative is that in 4.0 you load older version of Fuel >>> (the one in 3.0), then import, the expert, then load new fuel again. >>> >>> I have been doing this since Pharo 1.4 until 4.0 since my client's app >>> also uses Fuel. And the process was always quite simple and only once >>> per release. >>> >>> Migration is something we miss in Fuel..and even if we have promised >>> to keep format unchanged, sometimes the evolution of Pharo itself (not >>> the internal Fuel format representation) makes the format to be broken >>> from one version to the other. So until we have a better automagic >>> migration tool, the above trick should work. >>> >>> Also...see this >>> link: http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/FormatMigra… >>> >>> >>> Btw...here is the scrip I used to migrate from 1.8 to 1.9... this is >>> just an EXAMPLE of how you can do it..but do not copy it becuase it >>> uses old version of the code repositories, etc... >>> >>> >>> >>> | oldVersion newVersion fileNames objectsByFileName materializerClass | >>> >>> oldVersion := '1.8'. >>> newVersion := '1.9'. >>> fileNames := #( >>> >>> '/Users/mariano/XXX/aaaaDB.fdb' >>> '/Users/mariano/XXX/bbbbDB.fdb' >>> '/Users/mariano/XXX/ccccDB.fdb' >>> '/Users/mariano/XXX/ddddDB.fdb' >>> '/Users/mariano/XXX/eeeeDB.fdb' >>> '/Users/mariano/XXX/ffffDB.fdb' >>> ). >>> objectsByFileName := Dictionary new. >>> >>> materializerClass := Smalltalk at: #FLMaterializer. >>> >>> fileNames do: [ :fileName | >>> objectsByFileName >>> at: fileName >>> put: (materializerClass materializeFromFileNamed: fileName). >>> FileDirectory default copyFileNamed: fileName toFileNamed: fileName, >>> '-', oldVersion asString ]. >>> >>> Gofer it >>> squeaksource3: 'Fuel'; >>> package: 'ConfigurationOfFuel'; >>> load. >> >> This is the old repository. You should use >> >> Gofer it >> url: 'http://smalltalkhub.com/mc/Pharo/Fuel/main'; >> package: 'ConfigurationOfFuel'; >> load. >> ((Smalltalk at: #ConfigurationOfFuel) project version: â1.9.4') >> load. >> >> >> (See >> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Installation) >> >> >>> (ConfigurationOfFuel project version: newVersion) load. >>> >>> objectsByFileName keysAndValuesDo: [ :fileName :objects | >>> FLSerializer >>> serialize: objects >>> toFileNamed: fileName. >>> FileDirectory default copyFileNamed: fileName toFileNamed: fileName, >>> '-', newVersion asString >>> ]. >>> >>> >>> >>> On Thu, Apr 30, 2015 at 9:19 AM, Norbert Hartl <norbert(a)hartl.name >>> <mailto:norbert@hartl.name>> wrote: >>> >>> >>>> Am 30.04.2015 um 14:08 schrieb Johannes Rasche Kreuzberg >>>> <Johannes(a)Rasche-Kreuzberg.de <mailto:Johannes@Rasche-Kreuzberg.de>>: >>>> >>>> Hi folks, >>>> >>>> I'm just migrating to Pharo 4.0 >>>> >>>> On materialization of objects serialized under Pharo 3 >>>> an error was raised: different versions numbers ( 194 required ). >>>> >>>> Where does version 194 come from ? >>>> Monticello from Pharo 3 offers 193 >>>> >>>> Johannes >>>> >>> You need to add the repository of Fuel, load the ConfigurationOf >>> from there and you can upgrade to 1.9.4 >>> >>> The repository to add is >>> >>> http://smalltalkhub.com/mc/Pharo/Fuel/main >>> >>> Norbert >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> >> > > > -- > > /Johannes Rasche > Hagelberger Str. 56 > 10965 Berlin > fon +49 30 851 14 92 > mobil +49 1577 175 04 75 > mail Johannes(a)Rasche-Kreuzberg.de > www http://Rasche-Kreuzberg.de/ >

May 1, 2015

Next Pharo sprint & Moose dojo

by Jean-Christophe Bach

Hello Pharoers, We propose a Pharo sprint / Moose dojo on Friday, 22nd May, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come. JC

May 1, 2015

Re: [Pharo-dev] Are these changes good enough

by stepharo

Thanks Sergio Could you send the license agreement and send it to us? Stef Le 27/4/15 18:37, Sergio Fedi a Ã©crit : > Hi, I'm new to the Pharo community and recently installed Pharo 4.0. > > While using it I've found that the TestRunner didn't have coverage and > after investigating a little I've found that is was almost there and I > made it work. > > Is this change something I could submit as a Fix? > (as per in http://pharo.org/contribute-propose-fix) >

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by stepharo

Kind of because we got or: Boolean * block -> Object and now we have Object * Object -> Object I already discussed by emails too mcuh this point with marcus. Since we do not have even the start of a process to document the design rationale behind such decisions I will not discuss it. But I do not like that we have such ad-hoc process and I do not think that the ratio of impact and interest is valuable. Sure now we can define or: in our class and try to find its senders by browsing at least on of the 1590 senders (quite pratical). And if one day we will have a type inferencer for Pharo code we just removed some of the few cases where we could do something. (and this is true that Booleans are not the basis for building types analysis). Stef Le 1/5/15 11:58, Thierry Goubier a Ã©crit : > Le 01/05/2015 11:50, Marcus Denker a Ã©crit : >> >>> On 01 May 2015, at 11:48, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>>> >>>> To make the whole thing easier to understand we need to distinguish >>>> the two bugs. >>>> >>>> 1) or: is somehow special. No, it is not. We fixed that, but the >>>> fix was broken. >>> See my other mail. >>> I would add two different kind of rules to help people and slow the >>> use of redefinition of special selectors. >> >> >> I do not understand why. > > I side with Marcus there. Why? > > You now have a compiler which does not make those selectors special, > and you want to keep them special? > > Thierry > >> >> Marcus >> >> > > >

May 1, 2015

Re: [Pharo-dev] can or: be redefined?

by stepharo

Yes Le 1/5/15 11:52, Marcus Denker a Ã©crit : > >> On 01 May 2015, at 11:49, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 01 May 2015, at 11:46, stepharo <stepharo(a)free.fr >>> <mailto:stepharo@free.fr>> wrote: >>> >>> We should at least have a rules stating "pay attentino you use an >>> optimised selector". Im not sure what should be form of the warning >>> but we should make progress >>> >> >> why? >> >>> I see two cases >>> - the dev uses a non optimized version and the warning tell him >>> that it would be better to use the optimised >>> ifNil....of whatever case >>> >>> - when defining a method with such selector: >>> warn them because we should avoid them. >> >> > > I somehow feel that I did not manage to explain the whole thing in a > way that it was understandable. > Can we discuss that on the whiteboard next week? > > Marcus >

May 1, 2015