- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

On 21 Jul 2018, at 12:07, Norbert Hartl wrote: > Max, > > what do you think will be a proper fix for this? I cannot see if this > is a vm problem or not. In my opinion it should be fixed in Zinc as there's no way for the user of Zinc to flush the stream. The alternative would be for Zinc to expose a method or setting that allows the user to specify the expected behaviour. I do not think that this should be handled by the VM plugin or the stream class, as there are indeed different behaviours that make sense. Cheers, Max > > Norbert > >> Am 14.07.2018 um 08:25 schrieb Max Leske <maxleske(a)gmail.com>: >> >> Hi Nicolas, >> >> The PR you are referring [1] to concerns a missing fflush() when >> truncating a file. I believe that is a different case to this one, as >> a) the file is not truncated and b) in the case of truncation it is >> an explicit requirement that the file be empty before the first write >> happens. In our case, and in general, it depends on the situation >> whether flushing must occur immediately, e.g. because the file will >> be read again immediately, or not, e.g. when writing a data to a >> backup file. >> >> Thanks for the pointer though. >> >> >> Cheers, >> Max >> >> >> [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271 >> >>> On 12 Jul 2018, at 23:19, Nicolas Cellier wrote: >>> >>> Isn't there a recent PR on opensmalltalk that address just this? >>> >>>> Le jeu. 12 juil. 2018 Ã 23:16, Max Leske <maxleske(a)gmail.com> a >>>> Ã©crit : >>>> >>>> Hi Norbert, >>>> >>>> I was able to reproduce the problem and then identify the culprit, >>>> although what I don't yet understand is how this is related to the >>>> changes >>>> in Zinc. >>>> >>>> Anyway, the problem is that the file stream isn't properly flushed >>>> in >>>> ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as >>>> the last >>>> statement fixes your problem. Apparently, StandardFileStream / >>>> MultiByteFileStream perform a simple close() on the file which, >>>> according >>>> to the man page on close(), does *not* guarantee that the contents >>>> have >>>> all been written to file. In this case a flush is necessary because >>>> the >>>> entire file is immediately read again. >>>> >>>> Here's a smaller test case for you to play with Sven: >>>> >>>> ZnClient new >>>> url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; >>>> downloadTo: '/tmp/foobar.zip'. >>>> bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s >>>> | s contents ]. >>>> Transcript open; show: bytes size; cr. >>>> 5 seconds asDelay wait. >>>> Transcript show: ('/tmp/foobar.zip' asFileReference >>>> binaryReadStreamDo: [ :s | s contents ]) size. >>>> >>>> The output in the Transcript should be: >>>> >>>> 315392 >>>> 318420 >>>> >>>> Cheers, >>>> Max >>>> >>>> On 12 Jul 2018, at 8:17, Norbert Hartl wrote: >>>> >>>> Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: >>>> >>>> On 11 Jul 2018, at 22:44, Norbert Hartl wrote: >>>> >>>> Hi Max, >>>> >>>> I constructed a case that fails exactly like I experience it. Could >>>> you >>>> try? Just unpack the attachment on a linux, set PHARO_VM env to >>>> your >>>> executable and execute build.sh >>>> >>>> I will. Might take a couple of days though. >>>> >>>> No problem. Iâm happy if you find time. >>>> >>>> Norbert >>>> >>>> Max >>>> >>>> Norbert >>>> >>>> Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: >>>> >>>> On 10 Jul 2018, at 8:48, Norbert Hartl wrote: >>>> >>>> Max, >>>> >>>> thanks for taking the effort. >>>> >>>> No worries. >>>> >>>> Am 10.07.2018 um 08:37 schrieb Max Leske maxleske(a)gmail.com: >>>> >>>> I did my best to reproduce the issue but didn't have any luck. I >>>> really >>>> need access to a Linux VM to debug this. So I'm praying that Apple >>>> fixes >>>> the access restrictions to kernel extensions in their next beta... >>>> >>>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so >>>> there is >>>> indeed a chance that something goes wrong during download of the >>>> zip >>>> archive and that something may be tied to a difference in the >>>> versions of >>>> Zinc (although I still think that's unlikely). >>>> >>>> Yes there is potential but I donât see it. I take a fresh 6.1 >>>> image and >>>> load my project into. Iâm not sure but I think zinc 2.9.2 is >>>> loaded rather >>>> early in that process. So I wonder why it does not go wrong in the >>>> first >>>> phase. And also not if I load the test group within the first >>>> phase. >>>> It must be either the second Metacello invocation or the stopping, >>>> copying >>>> and starting of the image. >>>> I try to isolate this case more and provide a script that goes >>>> wrong on my >>>> machine. But it will take some time because I needed to stop trying >>>> to >>>> solve this as I wasted nearly two days on that already. >>>> >>>> Let me know once you have something and I'll try to help out. >>>> >>>> Norbert >>>> >>>> Max >>>> >>>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote: >>>> >>>> Am 09.07.2018 um 19:10 schrieb Max Leske maxleske(a)gmail.com: >>>> >>>> I checked the Parasol Archive and it does not appear to be in Zip64 >>>> format >>>> (Metacello uses ZipArchive which can't cope with Zip64 but >>>> ZipArchive can >>>> read the Parasol zip). So my next guess is that there's either a >>>> problem >>>> with Metacello or Pharo in the way that ZipArchive is used (e.g. >>>> endianness >>>> problem or non-binary stream data). It would therefore be helpful >>>> to find >>>> out what happens in ZipArchive>>readFrom:, i.e. what kind of stream >>>> is >>>> passed / opened, is it binary, does the file exist and is it still >>>> the >>>> correct file. >>>> >>>> I couldnât see anything obvious. The file in the debug message >>>> exists, it >>>> is a readable zip file. The way Metacello uses it it is a >>>> StandardFileStream. It switches it to binary in the code. >>>> But the only difference between a working and non-working build is >>>> the >>>> upgrade to zinc 2.9.2. >>>> >>>> Norbert >>>> >>>> I'd debug it myself but I can't run VirtualBox at the moment >>>> because I'm >>>> on the macOS beta and it won't start... >>>> >>>> Max >>>> >>>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >>>> >>>> Hi Max, >>>> >>>> Am 09.07.2018 um 18:18 schrieb Max Leske maxleske(a)gmail.com: >>>> >>>> Hi Norbert, >>>> >>>> This is a bit of a guess, but it's possible that the archive that >>>> is >>>> downloaded from github is in Zip64 format and that the libraries >>>> for >>>> extracting Zip64 are missing on your Linux. That would of course >>>> contradict >>>> the experience that the same operation appears to work in 6.1. >>>> >>>> to be honest I donât know what Zip64 format is. I thought the Zip >>>> classes >>>> are pure smalltalk for unpacking. >>>> >>>> Try extracting the archive manually on your Linux machine with the >>>> same >>>> method that Metacello uses (I assume, Metacello uses the ZipPlugin, >>>> which >>>> will probably use the system libraries). >>>> >>>> I have no ZipPlugin as library in any of my vms. >>>> >>>> But there are zips downloaded and unpacked. I start the image the >>>> first >>>> time loading all the code of my project. Then it is saved, copied >>>> to a new >>>> name and reopened to load the tests and then it fails. I did try to >>>> load >>>> the tests in the first run and then it works. >>>> >>>> Iâm running out of ideas >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> Cheers, >>>> Max >>>> >>>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>>> >>>> With the help of Esteban I got one step further. If I do >>>> >>>> MCWorkingCopy >>>> managersForClass: ZnFileSystemUtils >>>> do: [ :each | each ancestry initialize ] >>>> >>>> before loading my project it updates Zinc-FileSystem as well. Sadly >>>> it >>>> still does not work for me because I get >>>> >>>> Loading baseline of BaselineOfMobilityMap... >>>> ...RETRY->BaselineOfParasol >>>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>>> >>>> and I donât know why. zip file is downloaded from github and >>>> present but >>>> it fails and only on my jenkins on linux. On my Mac this works. >>>> >>>> I try a few things but then Iâm back on pharo6.1 for the time >>>> being :( >>>> >>>> Norbert >>>> >>>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl norbert(a)hartl.name: >>>> >>>> Really? I thought the same but then I didnât believe it works >>>> like that. >>>> >>>> Anyway this would be very easy to solve. We just need to ask Sven >>>> if he is >>>> fine with doing an empty .16 version for Zinc-FileSystem and does >>>> an >>>> in-place version reset of 2.9.2 or a new 2.9.3. Iâm not fully >>>> convinced >>>> that will solve it but the cost wonât be very high. >>>> >>>> Norbert >>>> >>>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot >>>> cyril.ferlicot(a)gmail.com: >>>> >>>> Need to investigate more. There are two .15 versions but there is 1 >>>> year >>>> in between (if you didnât notice TheIntegratior.15 is from 2017). >>>> Just want >>>> to have more context information because I can only see that this >>>> is >>>> strange but lacking insight. >>>> >>>> Iâm trying to figure out why it does not update Zinc-FileSystem. >>>> No matter >>>> what I do I cannot get Metacello to load the newer package. That >>>> would fix >>>> the issue because Iâm loading 2.9.2 which should have >>>> Zinc-FileSystem-SVC.15 and not stay on the one included in the >>>> image. >>>> >>>> I think this is important for everyone that has a product based on >>>> 6.1 and >>>> that want to migrate someday to pharo7. This way it is impossible >>>> to do it >>>> step by step. >>>> >>>> If there is a package .15 in the image and a package .15 in the >>>> repo, I >>>> think Metacello will not update because it rely on the numbers to >>>> know when >>>> to update. If it find a .15 and currently have a .15 I think >>>> Metacello will >>>> think they are at the same version. >>>> >>>> Norbert >>>> >>>> -- >>>> Cyril Ferlicot >>>> https://ferlicot.fr >>>> >>>> >> >> >>

July 21, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

Max, what do you think will be a proper fix for this? I cannot see if this is a vm problem or not. Norbert > Am 14.07.2018 um 08:25 schrieb Max Leske <maxleske(a)gmail.com>: > > Hi Nicolas, > > The PR you are referring [1] to concerns a missing fflush() when truncating a file. I believe that is a different case to this one, as a) the file is not truncated and b) in the case of truncation it is an explicit requirement that the file be empty before the first write happens. In our case, and in general, it depends on the situation whether flushing must occur immediately, e.g. because the file will be read again immediately, or not, e.g. when writing a data to a backup file. > > Thanks for the pointer though. > > > Cheers, > Max > > > [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/271 > >> On 12 Jul 2018, at 23:19, Nicolas Cellier wrote: >> >> Isn't there a recent PR on opensmalltalk that address just this? >> >>> Le jeu. 12 juil. 2018 Ã 23:16, Max Leske <maxleske(a)gmail.com> a Ã©crit : >>> >>> Hi Norbert, >>> >>> I was able to reproduce the problem and then identify the culprit, >>> although what I don't yet understand is how this is related to the changes >>> in Zinc. >>> >>> Anyway, the problem is that the file stream isn't properly flushed in >>> ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the last >>> statement fixes your problem. Apparently, StandardFileStream / >>> MultiByteFileStream perform a simple close() on the file which, according >>> to the man page on close(), does *not* guarantee that the contents have >>> all been written to file. In this case a flush is necessary because the >>> entire file is immediately read again. >>> >>> Here's a smaller test case for you to play with Sven: >>> >>> ZnClient new >>> url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; >>> downloadTo: '/tmp/foobar.zip'. >>> bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]. >>> Transcript open; show: bytes size; cr. >>> 5 seconds asDelay wait. >>> Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]) size. >>> >>> The output in the Transcript should be: >>> >>> 315392 >>> 318420 >>> >>> Cheers, >>> Max >>> >>> On 12 Jul 2018, at 8:17, Norbert Hartl wrote: >>> >>> Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: >>> >>> On 11 Jul 2018, at 22:44, Norbert Hartl wrote: >>> >>> Hi Max, >>> >>> I constructed a case that fails exactly like I experience it. Could you >>> try? Just unpack the attachment on a linux, set PHARO_VM env to your >>> executable and execute build.sh >>> >>> I will. Might take a couple of days though. >>> >>> No problem. Iâm happy if you find time. >>> >>> Norbert >>> >>> Max >>> >>> Norbert >>> >>> Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: >>> >>> On 10 Jul 2018, at 8:48, Norbert Hartl wrote: >>> >>> Max, >>> >>> thanks for taking the effort. >>> >>> No worries. >>> >>> Am 10.07.2018 um 08:37 schrieb Max Leske maxleske(a)gmail.com: >>> >>> I did my best to reproduce the issue but didn't have any luck. I really >>> need access to a Linux VM to debug this. So I'm praying that Apple fixes >>> the access restrictions to kernel extensions in their next beta... >>> >>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is >>> indeed a chance that something goes wrong during download of the zip >>> archive and that something may be tied to a difference in the versions of >>> Zinc (although I still think that's unlikely). >>> >>> Yes there is potential but I donât see it. I take a fresh 6.1 image and >>> load my project into. Iâm not sure but I think zinc 2.9.2 is loaded rather >>> early in that process. So I wonder why it does not go wrong in the first >>> phase. And also not if I load the test group within the first phase. >>> It must be either the second Metacello invocation or the stopping, copying >>> and starting of the image. >>> I try to isolate this case more and provide a script that goes wrong on my >>> machine. But it will take some time because I needed to stop trying to >>> solve this as I wasted nearly two days on that already. >>> >>> Let me know once you have something and I'll try to help out. >>> >>> Norbert >>> >>> Max >>> >>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote: >>> >>> Am 09.07.2018 um 19:10 schrieb Max Leske maxleske(a)gmail.com: >>> >>> I checked the Parasol Archive and it does not appear to be in Zip64 format >>> (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can >>> read the Parasol zip). So my next guess is that there's either a problem >>> with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness >>> problem or non-binary stream data). It would therefore be helpful to find >>> out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is >>> passed / opened, is it binary, does the file exist and is it still the >>> correct file. >>> >>> I couldnât see anything obvious. The file in the debug message exists, it >>> is a readable zip file. The way Metacello uses it it is a >>> StandardFileStream. It switches it to binary in the code. >>> But the only difference between a working and non-working build is the >>> upgrade to zinc 2.9.2. >>> >>> Norbert >>> >>> I'd debug it myself but I can't run VirtualBox at the moment because I'm >>> on the macOS beta and it won't start... >>> >>> Max >>> >>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >>> >>> Hi Max, >>> >>> Am 09.07.2018 um 18:18 schrieb Max Leske maxleske(a)gmail.com: >>> >>> Hi Norbert, >>> >>> This is a bit of a guess, but it's possible that the archive that is >>> downloaded from github is in Zip64 format and that the libraries for >>> extracting Zip64 are missing on your Linux. That would of course contradict >>> the experience that the same operation appears to work in 6.1. >>> >>> to be honest I donât know what Zip64 format is. I thought the Zip classes >>> are pure smalltalk for unpacking. >>> >>> Try extracting the archive manually on your Linux machine with the same >>> method that Metacello uses (I assume, Metacello uses the ZipPlugin, which >>> will probably use the system libraries). >>> >>> I have no ZipPlugin as library in any of my vms. >>> >>> But there are zips downloaded and unpacked. I start the image the first >>> time loading all the code of my project. Then it is saved, copied to a new >>> name and reopened to load the tests and then it fails. I did try to load >>> the tests in the first run and then it works. >>> >>> Iâm running out of ideas >>> >>> thanks, >>> >>> Norbert >>> >>> Cheers, >>> Max >>> >>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>> >>> With the help of Esteban I got one step further. If I do >>> >>> MCWorkingCopy >>> managersForClass: ZnFileSystemUtils >>> do: [ :each | each ancestry initialize ] >>> >>> before loading my project it updates Zinc-FileSystem as well. Sadly it >>> still does not work for me because I get >>> >>> Loading baseline of BaselineOfMobilityMap... >>> ...RETRY->BaselineOfParasol >>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>> >>> and I donât know why. zip file is downloaded from github and present but >>> it fails and only on my jenkins on linux. On my Mac this works. >>> >>> I try a few things but then Iâm back on pharo6.1 for the time being :( >>> >>> Norbert >>> >>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl norbert(a)hartl.name: >>> >>> Really? I thought the same but then I didnât believe it works like that. >>> >>> Anyway this would be very easy to solve. We just need to ask Sven if he is >>> fine with doing an empty .16 version for Zinc-FileSystem and does an >>> in-place version reset of 2.9.2 or a new 2.9.3. Iâm not fully convinced >>> that will solve it but the cost wonât be very high. >>> >>> Norbert >>> >>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot cyril.ferlicot(a)gmail.com: >>> >>> Need to investigate more. There are two .15 versions but there is 1 year >>> in between (if you didnât notice TheIntegratior.15 is from 2017). Just want >>> to have more context information because I can only see that this is >>> strange but lacking insight. >>> >>> Iâm trying to figure out why it does not update Zinc-FileSystem. No matter >>> what I do I cannot get Metacello to load the newer package. That would fix >>> the issue because Iâm loading 2.9.2 which should have >>> Zinc-FileSystem-SVC.15 and not stay on the one included in the image. >>> >>> I think this is important for everyone that has a product based on 6.1 and >>> that want to migrate someday to pharo7. This way it is impossible to do it >>> step by step. >>> >>> If there is a package .15 in the image and a package .15 in the repo, I >>> think Metacello will not update because it rely on the numbers to know when >>> to update. If it find a .15 and currently have a .15 I think Metacello will >>> think they are at the same version. >>> >>> Norbert >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr >>> >>> > > >

July 21, 2018

Re: [Pharo-dev] RHEL/CentOS vs. libgit2 vs. libcurl-gnutls.so.4 vs. 64bit default VM from pharo.org and repos - report

by Sean P. DeNigris

Thanks for the report! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

July 19, 2018

RHEL/CentOS vs. libgit2 vs. libcurl-gnutls.so.4 vs. 64bit default VM from pharo.org and repos - report

by Petr Fischer

Hello, Pharo situation on the CentOS/RHEL - major server side Linux distribution: 1) VM installation via this (CentOS7 section via pharo centos repo): https://pharo.org/gnu-linux-installation-64 Broken. There is no libgit2.so in /usr/lib64/pharo6-vm/ So no git/iceberg, game over (can't load today library dependencies hosted on github). There is probably obsolete VM build in pharo CentOS repository. 2) manual download VM standalone "Pharo 6.1 for GNU/Linux (64bit)" from: http://pharo.org/download OK, in this zip package, there is libgit2.so, which has these deps: ... linux-vdso.so.1 => (0x00007ffdb0bfe000) libcurl-gnutls.so.4 => /lib64/libcurl-gnutls.so.4 (0x00007fc67dae8000) libz.so.1 => /lib64/libz.so.1 (0x00007fc67d8d2000) ... But there is no curl-gnutls.so.4 on CentOS7, only libcurl.so.4 (in package libcurl). Result is: no git/iceberg -> game over. Workaround is: cd /usr/lib64 ln -s libcurl.so.4 libcurl-gnutls.so.4 ---------- Solutions: 1) pharo CentOS VM repository needs to be updated (and make the libcurl link in the rpm post installation step) 2) PLEASE - add information about linking libcurl-gnutls.so.4 to the CentOS7 sections (and maybe CentOS6) here: https://pharo.org/gnu-linux-installation-64 End of report, pf

July 19, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Reg Krock

Hi Damien, Frames and Slots come from the AI world. The terms were defined by Marvin Minsky in his paper "A Framework for Representing Knowledge", Marvin Minsky, MIT-AI Laboratory Memo 306, June, 1974. ( https://web.media.mit.edu/~minsky/papers/Frames/frames.html) Minsky realized that the AI world was looking at âintelligenceâ from a perspective of small pieces. He challenges the AI world to start looking at things in a bigger picture. One of his exampleâs is a chair. He believed we have a âFrameâ which is the general shape of a chair. The Chair frame has âslotsâ which represent details of the chair. The contents of a slot can be another âframeâ. In Smalltalk the Frame is analogous to a Class and a slot is somewhat analogous to an instance variable. A key paper which describes the implementation of frames and slots in the AI world is: "The Design Space of Frame Knowledge Representation Systemsâ by Peter Karp. ( https://www.sri.com/work/publications/design-space-frame-knowledge-represen… ). These are both old papers but they will give you the essence of what Frames and Slots from the AI world. In the 90âs there work done on the development of frame systems in Smalltalk. There are several very large Frame and Slot systems still in production. I hope this helps. Regards, Reg > On 18 Jul2018, at 8:39 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > I understand what slots are, but haven't heard of frames in this contextâ¦ can you elaborate ? > > On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev <pharo-dev(a)lists.pharoorg <mailto:pharo-dev@lists.pharo.org>> wrote: > The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought. > > I suspect that you will find that many more changes will be discovered as work is done with it. > > Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model. > > I also would suggest careful examination of when to use composition versus traits with slots. > > Regards > > Reg Krock > > > > On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > > > tesonep(a)gmail.com <mailto:tesonep@gmail.com> wrote > >> the one that is disturbing, it is kept for > >> compatibility with the old behavior > > > > Are there enough users to justify backward compatibility if it costs a nice > > API? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> > > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet <http://people.untyped.org/damien.pollet>

July 18, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Norbert Hartl

> Am 18.07.2018 um 14:39 schrieb Damien Pollet <damien.pollet(a)gmail.com>: > > I understand what slots are, but haven't heard of frames in this contextâ¦ can you elaborate ? > +1 Norbert > On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: > The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought. > > I suspect that you will find that many more changes will be discovered as work is done with it. > > Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model. > > I also would suggest careful examination of when to use composition versus traits with slots. > > Regards > > Reg Krock > > > > On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > > > tesonep(a)gmail.com <mailto:tesonep@gmail.com> wrote > >> the one that is disturbing, it is kept for > >> compatibility with the old behavior > > > > Are there enough users to justify backward compatibility if it costs a nice > > API? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> > > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet <http://people.untyped.org/damien.pollet>

July 18, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Damien Pollet

I understand what slots are, but haven't heard of frames in this contextâ¦ can you elaborate ? On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > The Slot class implementation is fundamentally sound but the larger > constructs surrounding Frames and Slots still requires extensive thought. > > I suspect that you will find that many more changes will be discovered as > work is done with it. > > Slots provide the capacity to implement most of AOP concepts in a simple > manner. It also results in a Frame model. > > I also would suggest careful examination of when to use composition versus > traits with slots. > > Regards > > Reg Krock > > > > On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > tesonep(a)gmail.com wrote > >> the one that is disturbing, it is kept for > >> compatibility with the old behavior > > > > Are there enough users to justify backward compatibility if it costs a > nice > > API? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 18, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Reg Krock

The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought. I suspect that you will find that many more changes will be discovered as work is done with it. Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model. I also would suggest careful examination of when to use composition versus traits with slots. Regards Reg Krock > On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > tesonep(a)gmail.com wrote >> the one that is disturbing, it is kept for >> compatibility with the old behavior > > Are there enough users to justify backward compatibility if it costs a nice > API? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

July 18, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Denis Kudriashov

Hi 2018-07-17 9:55 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Hi Torsten, > the problem is defining the behavior expected from the set of messages: > > Today we have 3 (yes 3.... awful) they are to keep compatibility with the > tools, we have to continue improving them. > > - allSlots: returns all the slots defined in the hierarchy, in the same > class and in all the traits used in the hierarchy. > - localSlots: returns the slots that are defined in the own class without > the ones in the traits. > - slots: returns the slots that are defined in the class and not in the > superclasses. > > The last message is the one that is disturbing, it is kept for > compatibility with the old behavior. In my opinion, localSlots should be > removed, and slots behave like localSlots. > Would be nice to have it consistent with #methods and #localMethods. I would prefer explicit names like definedSlots, owningSlots (if needed). And same for methods. > It requires to change the tools. > > If we need to know where the slots are defined we can ask the slots, the > slots know which is the class using the slot and where it is defined. > > So, I will like to improve in any way. > About the implementation I like the one in #localSlots. > But it requires some work or letting the stuff broken until we fix them. > > Cheers, > Pablo > > On Tue, Jul 17, 2018 at 10:19 AM Torsten Bergmann <astares(a)gmx.de> wrote: > >> I guess I found a bug in accessing Slots using #slots in combination with >> IndexedSlots and traits. >> To reproduce use latest Pharo 7 (Build 1126) >> >> First create a class with a slot, note that the slot needs to be : >> >> Object subclass: #ClassA >> slots: { IndexedSlot named: #upper } >> classVariables: { } >> package: 'Slot-Bugs' >> >> As it is the first slot it internally receives an index 1 as you can >> check with "ClassA slots first". >> >> Now define a stateful trait with another indexed slot: >> >> Trait named: #StatefulTrait >> uses: {} >> slots: { IndexedSlot named: #slotFromTrait } >> category: 'Slot-Bugs' >> >> And create a new subclass using the new Trait >> >> ClassA subclass: #ClassB >> uses: StatefulTrait >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'Slot-Bugs' >> >> >> 1. when you evaluate "ClassA slots" it returns {#FirstSlot => Slot} >> which is correct >> 2. when you evaluate "StatefulTrait slots" it returns {#slotFromTrait => >> Slot} which is correct >> 3. when you evaluate "ClassB allSlots" returns "an >> OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => >> InstanceVariableSlot)" which is OK >> >> but >> >> 4. when you evaluate "ClassB slots" it returns {#slotFromTrait => >> InstanceVariableSlot} which is NOT correct as class B does not define the >> slot, it is defined in the trait >> >> >> So I think 4. is wrong and reasons is the implementation of #slot: >> >> slots >> "I remove the slots comming from a traitComposition" >> ^ super slots reject:[ :e | self traitComposition slots >> includes:e ] >> >> If you debug you will notice that >> >> super slots returns our #slotFromTrait with an index >> of 2 while >> self traitComposition slots returns our #slotFromTrait with an index >> of 1 while >> >> which is the same #slotFromTrait but a different index - therefore it >> does not get removed. >> >> >> Dont know what is the best way to fix this without any side effects. >> Commenst and help appreciated. >> >> Thanks >> T. >> >> > > -- > Pablo Tesone. > tesonep(a)gmail.com >

July 17, 2018

Re: [Pharo-dev] [ANN] Pharo Git Thermite Release

by Alexandre Bergel

It would be fantastic that people try it out. It is easy to use, and is really a big improvement over the tool set we use. And getting feedback is important. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jul 17, 2018, at 11:08 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hello, > > I am finally releasing an initial public version of Pharo Git Thermite, a tool that I am developing as part of my master thesis for visualizing Monticello and Git commits, for Pharo and Python: > > GitHub Page with sources/documentation/issue tracker: https://github.com/ronsaldo/pharo-git-thermite <https://github.com/ronsaldo/pharo-git-thermite> > > Short video examples: > - Monticello Visualization; https://youtu.be/02CUHBmm-K8 <https://youtu.be/02CUHBmm-K8> > - GitHub pull request: https://youtu.be/f196btLfYxM <https://youtu.be/f196btLfYxM> > - Local git commit: https://youtu.be/LCHTiJ4nx3g <https://youtu.be/LCHTiJ4nx3g> > > Feedback form: https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl… <https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl…> > > Best regards, > Ronie > > <thermite-visualization.png> >

July 17, 2018