July 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Vm-dev] FileSystem file attributes and #isSymlink patch

by Alistair Grant

Hi All, I've realised that I have been doing all my development using an old version of VMMaker: dtl.392. Before submitting my plugin I thought I should check that it builds correctly with the latest VMMaker. However taking a clean squeak image (Squeak5.1-16549-32bit-201608171728-Linux) and loading what I believe is the latest VMMaker: oscog-eem.2257 causes the plugin to fail to compile with numerous errors (on Ubuntu 16.04, gcc 4.8.5). Could someone please let me know which version of VMMaker I should be using? If you're interested in the sorts of problems I'm facing: The full code is available from: MCHttpRepository location: 'http://smalltalkhub.com/mc/Alistair/FileAttributesPlugin/main' user: '' password: '' An example of one of the failures is a method that begins: fileToAttributeArray: cPathName mask: attributeMask array: attributeArray "Answer a file attribute array from pathNameOop." | getStats useLstat getAccess statArray accessArray combinedArray status fileNameOop statBuf statBufPointer | <returnTypeC: 'int'> <var: 'cPathName' type: 'char *'> <var: 'attributeArray' type: 'sqInt *'> <var: 'statBuf' type: 'struct stat'> <var: 'statBufPointer' declareC: 'struct stat *statBufPointer= &statBuf'> dtl.392 correctly creates C definitions for statBuf and statBufPointer, i.e.: static int fileToAttributeArraymaskarray(char *cPathName, sqInt attributeMask, sqInt *attributeArray) { sqInt accessArray; sqInt combinedArray; sqInt fileNameOop; sqInt getAccess; sqInt getStats; sqInt statArray; struct stat statBuf; struct stat *statBufPointer= &statBuf; sqInt status; sqInt useLstat; oscog-eem.2257 produces: static int fileToAttributeArraymaskarray(char *cPathName, sqInt attributeMask, sqInt *attributeArray) { sqInt accessArray; sqInt combinedArray; sqInt fileNameOop; int getAccess; int getStats; sqInt statArray; struct stat *statBufPointer= &statBuf; sqInt status; int useLstat; As can be seen, the statBuf declaration is missing. Further along: isSymlink: cPathName boolean: resultOop "Set resultOop to a boolean indicating whether cPathName is a symbolic link. Answer status (0 = success)" | status statBuf | <var: 'cPathName' type: 'char *'> <var: 'resultOop' type: 'sqInt *'> <var: 'statBuf' type: 'struct stat'> self isDefinedTrueExpression: 'HAVE_LSTAT == 1' inSmalltalk: [] comment: '' ifTrue: [ status := self cCode: 'lstat(cPathName, &statBuf)'. (status ~= 0) ifTrue: [^self cantStatPath]. ((self cCode: 'S_ISLNK(statBuf.st_mode)') = 0) ifFalse: [self cCode: '*resultOop = interpreterProxy->trueObject()'] ifTrue: [self cCode: '*resultOop = interpreterProxy->falseObject()']. ] ifFalse: []. ^0 dtl.392 produces: static sqInt isSymlinkboolean(char *cPathName, sqInt *resultOop) { struct stat statBuf; sqInt status; # if (HAVE_LSTAT == 1) // status = lstat(cPathName, &statBuf); if (status != 0) { return -3; } if ((S_ISLNK(statBuf.st_mode)) == 0) { *resultOop = interpreterProxy->falseObject(); } else { *resultOop = interpreterProxy->trueObject(); } # endif // HAVE_LSTAT == 1 return 0; } oscog-eem.2257 produces: static sqInt isSymlinkboolean(char *cPathName, sqInt *resultOop) { struct stat statBuf; sqInt status; isDefinedTrueExpressioninSmalltalkcommentifTrueifFalse("HAVE_LSTAT == 1", null, "", ((status = lstat(cPathName, &statBuf)), (status != 0 ? (/* begin cantStatPath */ return -3) : 0), ((S_ISLNK(statBuf.st_mode)) == 0 ? *resultOop = interpreterProxy->falseObject() : *resultOop = interpreterProxy->trueObject())), null); return 0; } Any help appreciated. Thanks very much, Alistair On Tue, Jul 25, 2017 at 03:21:16PM +0000, Alistair Grant wrote: > > I'll post another reply once I've got the plugin code in > smalltalkhub.com. > > Thanks again, > Alistair

July 26, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Stephane Ducasse

Hi Nicolai Athens is important for us too. Now none of us in the team has the experience in Cairo. Users of Athens usually do not want to invest understanding it either. I tried to create the conditions that Igor could stay in the communautee but it failed because alone I could not do it. Now Athens is what is in Pharo. I have no idea of the rest. Stef On Wed, Jul 26, 2017 at 4:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2017-07-26 16:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> I imagine that hot-fixes means when we found a serious bug in the >> alpha version and see that it is also in the previous version. >> >> Now Hilaire if you want a change to be integrated in Pharo and Pharo >> 60 for example. >> >> - we should have a bug entry on fogbugz (you see when I read the >> emails I do not see the bug entry >> so I have to look for it and lose time - because crawling the bug >> database is tedious, so this is a lot more efficient to send also bug >> entries). >> - we should have a fix. >> - it should be tagged for Pharo 60. >> - it should be validated (pass the tests). >> >> Each time we introduce a fix, we may break sometimes so we pay really >> attention to have >> limited fixes with limited impact. >> >> For the ones you mentioned: >> >> - I cannot find the PNGReader bug entry. I read all the mails of the >> thread. >> So this is not efficient. >> >> - https://pharo.fogbugz.com/f/cases/20166/ is there but there is no >> fix so we will have > > > The problem with fixes for Athens is, that nobody could tell we what the > current state is. > > http://forum.world.st/current-athens-configuration-td4914441.html#a4914488 > > the latest changes are from alexej and I guess they are important for sparta > and the further development for bloc/sparte for pharo 7/8 > We can not just take the latest version and put it in pharo 6, and hope that > it will work. > We need for this external package a good communication about changes and > versions. > This did not happen here. And I am not sure if we maybe already put some > changes in pharo 6, that are not at the athens repository. > I once considered athens as an important package for the new pharo ui, but > the way it is handled now looks more like abandoned. > > that is the reason why I just put the fix for 20166 in the comment of the > bug entry instead of providing a slice / or update the version on the > repository. > > > It is ok if we tell hilaire to not just put bugreports on the ml but create > a bug report on fogbugz instead. So people can fix/provide a slice and run > the validation. > But this happend in this case. It is just that we do not get it right to > handle this case because it depens on athens. > > >> >> >> People are nice and trying to help now everybody has its own agenda >> and we set these "rules" >> to avoid that we all lose time. If you want that people help you then >> try to adhere to such best >> practices. >> >> Follow the Pharo process. >> >> Stef. >> >> >> On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hilaire(a)drgeo.eu> wrote: >> > Hi, >> > >> > It is the other minor bugs fixes details which were missing. >> > >> > What is hot-fixes? >> > >> > Hilaire >> > >> > >> > -- >> > Dr. Geo >> > http://drgeo.eu >> > >> > >> > >> >

July 26, 2017

GTInspector and sorting in dictionaries

by Holger Freyther

Hey, I have a simple dictionary with class as the key and a number as value. In the inspector I try to sort it by the value. But it is doing an alphabetical sort and not numerical? I can change Dictionary>>#gtInspectorItemsIn: to pass a sortedBy: block when adding the value column but is "<" a general usable protocol? How would one specialize the sort depending on the data in the dictionary? Any ideas how to get numbers sorted intuitively without adding too much magic (trying to convert the string representation back to a number, custom GTTablePresentation, using "a value < b value" and use the string representation if that fails..)? cheers holger

July 26, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Nicolai Hess

2017-07-26 16:42 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-26 16:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> I imagine that hot-fixes means when we found a serious bug in the >> alpha version and see that it is also in the previous version. >> >> Now Hilaire if you want a change to be integrated in Pharo and Pharo >> 60 for example. >> >> - we should have a bug entry on fogbugz (you see when I read the >> emails I do not see the bug entry >> so I have to look for it and lose time - because crawling the bug >> database is tedious, so this is a lot more efficient to send also bug >> entries). >> - we should have a fix. >> - it should be tagged for Pharo 60. >> - it should be validated (pass the tests). >> >> Each time we introduce a fix, we may break sometimes so we pay really >> attention to have >> limited fixes with limited impact. >> >> For the ones you mentioned: >> >> - I cannot find the PNGReader bug entry. I read all the mails of the >> thread. >> So this is not efficient. >> >> - https://pharo.fogbugz.com/f/cases/20166/ is there but there is no >> fix so we will have >> > > The problem with fixes for Athens is, that nobody could tell we what the > current state is. > > http://forum.world.st/current-athens-configuration-td4914441.html#a4914488 > > the latest changes are from alexej and I guess they are important for > sparta and the further development for bloc/sparte for pharo 7/8 > We can not just take the latest version and put it in pharo 6, and hope > that it will work. > We need for this external package a good communication about changes and > versions. > This did not happen here. And I am not sure if we maybe already put some > changes in pharo 6, that are not at the athens repository. > I once considered athens as an important package for the new pharo ui, but > the way it is handled now looks more like abandoned. > > that is the reason why I just put the fix for 20166 in the comment of the > bug entry instead of providing a slice / or update the version on the > repository. > > > It is ok if we tell hilaire to not just put bugreports on the ml but > create a bug report on fogbugz instead. So people can fix/provide a slice > and run the validation. > But this happend in this case. It is just that we do not get it right to > handle this case because it depens on athens. > whatever, put a slice for this case into the inbox SLICE-Issue-20166-wrong-cliprect-on-transformed-athens-canvas-NicolaiHess.1 > > > >> >> People are nice and trying to help now everybody has its own agenda >> and we set these "rules" >> to avoid that we all lose time. If you want that people help you then >> try to adhere to such best >> practices. >> >> Follow the Pharo process. >> >> Stef. >> >> >> On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hilaire(a)drgeo.eu> wrote: >> > Hi, >> > >> > It is the other minor bugs fixes details which were missing. >> > >> > What is hot-fixes? >> > >> > Hilaire >> > >> > >> > -- >> > Dr. Geo >> > http://drgeo.eu >> > >> > >> > >> >> >

July 26, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Nicolai Hess

2017-07-26 16:25 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > I imagine that hot-fixes means when we found a serious bug in the > alpha version and see that it is also in the previous version. > > Now Hilaire if you want a change to be integrated in Pharo and Pharo > 60 for example. > > - we should have a bug entry on fogbugz (you see when I read the > emails I do not see the bug entry > so I have to look for it and lose time - because crawling the bug > database is tedious, so this is a lot more efficient to send also bug > entries). > - we should have a fix. > - it should be tagged for Pharo 60. > - it should be validated (pass the tests). > > Each time we introduce a fix, we may break sometimes so we pay really > attention to have > limited fixes with limited impact. > > For the ones you mentioned: > > - I cannot find the PNGReader bug entry. I read all the mails of the > thread. > So this is not efficient. > > - https://pharo.fogbugz.com/f/cases/20166/ is there but there is no > fix so we will have > The problem with fixes for Athens is, that nobody could tell we what the current state is. http://forum.world.st/current-athens-configuration-td4914441.html#a4914488 the latest changes are from alexej and I guess they are important for sparta and the further development for bloc/sparte for pharo 7/8 We can not just take the latest version and put it in pharo 6, and hope that it will work. We need for this external package a good communication about changes and versions. This did not happen here. And I am not sure if we maybe already put some changes in pharo 6, that are not at the athens repository. I once considered athens as an important package for the new pharo ui, but the way it is handled now looks more like abandoned. that is the reason why I just put the fix for 20166 in the comment of the bug entry instead of providing a slice / or update the version on the repository. It is ok if we tell hilaire to not just put bugreports on the ml but create a bug report on fogbugz instead. So people can fix/provide a slice and run the validation. But this happend in this case. It is just that we do not get it right to handle this case because it depens on athens. > > People are nice and trying to help now everybody has its own agenda > and we set these "rules" > to avoid that we all lose time. If you want that people help you then > try to adhere to such best > practices. > > Follow the Pharo process. > > Stef. > > > On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > > Hi, > > > > It is the other minor bugs fixes details which were missing. > > > > What is hot-fixes? > > > > Hilaire > > > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > > >

July 26, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Stephane Ducasse

I imagine that hot-fixes means when we found a serious bug in the alpha version and see that it is also in the previous version. Now Hilaire if you want a change to be integrated in Pharo and Pharo 60 for example. - we should have a bug entry on fogbugz (you see when I read the emails I do not see the bug entry so I have to look for it and lose time - because crawling the bug database is tedious, so this is a lot more efficient to send also bug entries). - we should have a fix. - it should be tagged for Pharo 60. - it should be validated (pass the tests). Each time we introduce a fix, we may break sometimes so we pay really attention to have limited fixes with limited impact. For the ones you mentioned: - I cannot find the PNGReader bug entry. I read all the mails of the thread. So this is not efficient. - https://pharo.fogbugz.com/f/cases/20166/ is there but there is no fix so we will have People are nice and trying to help now everybody has its own agenda and we set these "rules" to avoid that we all lose time. If you want that people help you then try to adhere to such best practices. Follow the Pharo process. Stef. On Tue, Jul 25, 2017 at 6:01 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > It is the other minor bugs fixes details which were missing. > > What is hot-fixes? > > Hilaire > > > -- > Dr. Geo > http://drgeo.eu > > >

July 26, 2017

Re: [Pharo-dev] Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU

by Henrik Sperre Johansen

There's https://pharo.fogbugz.com/f/cases/20112/, your error could be the same. (a multibyte character crossing the initial-guess block boundary) As outlined there, the (temp) fix is to put an error handler around the nextEntryPositionIfFound:ifNone: call in refreshNewBlocksFrom: Cheers, Henry -- View this message in context: http://forum.world.st/Lots-of-UTF8InvalidText-Invalid-utf8-input-detected-f… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 26, 2017

Re: [Pharo-dev] Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU

by Max Leske

On 25 July 2017 at 22:55:19, Mariano Martinez Peck (marianopeck(a)gmail.com) wrote: Guys, I am getting "UTF8InvalidText: Invalid utf8 input detected" quite frequently on Pharo 6.0 which come from ombu background job. Has anything seen this too? Quite annoying... Yes, I've seen it a couple of times. No clue though why it happens, or when. This is not the first time I hit it. This time I analyzed a bit why it was failing and it's because I removed a method manually...I mean, I did MyClass removeSelector: #myMethod And the omEntry is a EpMethodRemoval which represents the exact method I deleted... Also I can see the MultiByteFileStream internal 'collection' is full of none ascii things. I can share a fuelout as well as the image with the files if you want. I can also share the ombu file in question. Contact me in private. ---- [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: UTF8InvalidText(Exception)>>signal UTF8InvalidText(Exception)>>signal: UTF8TextConverter>>errorMalformedInput UTF8TextConverter>>nextFromStream: MultiByteFileStream>>next MultiByteFileStream(PositionableStream)>>match: MultiByteFileStream(PositionableStream)>>upToAll: OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: OmBlockFileStore>>refreshNewBlocksFrom: [ :readStream | self refreshNewBlocksFrom: readStream ] in OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: in Block: [ :readStream | self refreshNewBlocksFrom: readStr...etc... [ ^ aBlockClosure value: readStream ascii ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure value: readStream ascii ] BlockClosure>>on:do: [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | ... [ aBlock value: stream ] in FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock value: stream ] BlockClosure>>ensure: FileReference(AbstractFileReference)>>readStreamDo: OmBlockFileStore(OmFileStore)>>readEntriesWith: OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: [ | initialPosition initialLocalName | self entryBuffer isEmpty ifTrue: [ ^ self ]. fileReference writeStreamDo: [ :fileStream | fileStream setToEnd. initialPosition := fileStream position. initialLocalName := self entryBuffer first value. ZnBufferedWriteStream on: fileStream do: [ :aWriteStream | | anEntryWriter | anEntryWriter := self newEntryWriter. [ self entryBuffer isEmpty ] whileFalse: [ | next entry | next := self entryBuffer removeFirst. entry := next key. "Write entry to file" anEntryWriter on: aWriteStream nextEntryPut: entry ] ]. "In Linux it was necessary to explicitely flush the file stream" fileStream flush. lastStreamPosition := fileStream size ]. self refreshEntryPositionsByLocalNameStartingAt: initialPosition since: initialLocalName ] in OmBlockFileStore(OmFileStore)>>flushEntryBuffer in Block: [ | initialPosition initialLocalName |... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: OmBlockFileStore(OmFileStore)>>critical: OmBlockFileStore(OmFileStore)>>flushEntryBuffer OmDeferrer>>sendMessage [ self sendMessage ] in OmDeferrer>>flush in Block: [ self sendMessage ] -- Mariano http://marianopeck.wordpress.com

July 26, 2017

Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU

by Mariano Martinez Peck

Guys, I am getting "UTF8InvalidText: Invalid utf8 input detected" quite frequently on Pharo 6.0 which come from ombu background job. Has anything seen this too? Quite annoying... This is not the first time I hit it. This time I analyzed a bit why it was failing and it's because I removed a method manually...I mean, I did MyClass removeSelector: #myMethod And the omEntry is a EpMethodRemoval which represents the exact method I deleted... Also I can see the MultiByteFileStream internal 'collection' is full of none ascii things. I can share a fuelout as well as the image with the files if you want. I can also share the ombu file in question. Contact me in private. ---- [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ... BlockClosure>>cull: Context>>evaluateSignal: Context>>handleSignal: UTF8InvalidText(Exception)>>signal UTF8InvalidText(Exception)>>signal: UTF8TextConverter>>errorMalformedInput UTF8TextConverter>>nextFromStream: MultiByteFileStream>>next MultiByteFileStream(PositionableStream)>>match: MultiByteFileStream(PositionableStream)>>upToAll: OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: OmBlockFileStore>>refreshNewBlocksFrom: [ :readStream | self refreshNewBlocksFrom: readStream ] in OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: in Block: [ :readStream | self refreshNewBlocksFrom: readStr...etc... [ ^ aBlockClosure value: readStream ascii ] in [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure value: readStream ascii ] BlockClosure>>on:do: [ :readStream | [ ^ aBlockClosure value: readStream ascii ] on: Error do: [ :error | (OmFileStoreReadingError readingError: error on: self fileReference position: readStream position) signal ] ] in OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | ... [ aBlock value: stream ] in FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock value: stream ] BlockClosure>>ensure: FileReference(AbstractFileReference)>>readStreamDo: OmBlockFileStore(OmFileStore)>>readEntriesWith: OmBlockFileStore>>refreshEntryPositionsByLocalNameStartingAt:since: [ | initialPosition initialLocalName | self entryBuffer isEmpty ifTrue: [ ^ self ]. fileReference writeStreamDo: [ :fileStream | fileStream setToEnd. initialPosition := fileStream position. initialLocalName := self entryBuffer first value. ZnBufferedWriteStream on: fileStream do: [ :aWriteStream | | anEntryWriter | anEntryWriter := self newEntryWriter. [ self entryBuffer isEmpty ] whileFalse: [ | next entry | next := self entryBuffer removeFirst. entry := next key. "Write entry to file" anEntryWriter on: aWriteStream nextEntryPut: entry ] ]. "In Linux it was necessary to explicitely flush the file stream" fileStream flush. lastStreamPosition := fileStream size ]. self refreshEntryPositionsByLocalNameStartingAt: initialPosition since: initialLocalName ] in OmBlockFileStore(OmFileStore)>>flushEntryBuffer in Block: [ | initialPosition initialLocalName |... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: OmBlockFileStore(OmFileStore)>>critical: OmBlockFileStore(OmFileStore)>>flushEntryBuffer OmDeferrer>>sendMessage [ self sendMessage ] in OmDeferrer>>flush in Block: [ self sendMessage ] -- Mariano http://marianopeck.wordpress.com

July 25, 2017

Re: [Pharo-dev] [Vm-dev] FileSystem file attributes and #isSymlink patch

by Stephane Ducasse

Hi Alistair Yes it should become part of the core of Pharo :). Stef On Tue, Jul 25, 2017 at 5:21 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi David, > > Thanks very much for your follow-up. > > On Mon, Jul 24, 2017 at 07:28:07PM -0400, David T. Lewis wrote: >> >> Hi Alistair, >> >> I am copying this to vm-dev for follow up on the plugin, see below. >> >> >> On Mon, Jul 24, 2017 at 08:09:10AM +0000, Alistair Grant wrote: >> > Hi All, >> > >> > I'm nearly ready to submit a patch that started with the goal of being >> > able to retrieve the device id and fixing FileReference>>isSymlink and >> > also follows Esteban's suggestion of splitting out file existence and >> > other attributes (which provides a performace gain). See the summary >> > below for a description of the changes. >> > >> > The patch involves adding a new VM plugin, FileAttriubutesPlugin. To >> > minimise the chance of any problems along the way I'd like to submit the >> > patch in three steps: >> > >> > 1. Add the VM plugin (FileAttributesPlugin) >> > 2. Add the code the image that allows testing of the code and plugin, >> > but doesn't do any integration with existing functionality. >> > This will allow the plugin to be tested by a few volunteers >> > (hopefully). >> > 3. Add the patches that make the switch over to the new implementation. >> > >> >> I think you are handling this in exactly the right way, kudos. >> >> > >> > Can someone point me to how to submit a new VM plugin? The code is >> > contained in a subclass of InterpreterPlugin. >> >> Following up on the vm-dev list: If your plugin is available in a Monticello >> repository, that would be great because VM builders can easily include it >> and try it out. Any repository would be fine for starters, or if you have >> an account on squeaksource.com I can add you as developer in the somewhat >> loosely-related DirectoryPlugin project if that is of any help. Whatever is >> convenient for you. > > smalltalkhub.com is probably easiest for me, thanks. > > >> Your plugin sounds like something that would be stable and require little >> maintenance over time, so it might make sense to pull it directly into >> the VMMaker package. We can discuss that vm-dev list. > > I'm hoping this will become a core part of Pharo, so ultimately it > should live with the other Pharo core plugins like FilePlugin (assuming > it is accepted, of course). > > >> Once your plugin code is available, it should be straighforward to start >> including it in the various VM build configurations. > > Great, thanks. build.linux32x86/pharo.cog.spur is probably the best > place to start. > > I should be able to post the plugin to smalltalkhub.com quite > quickly. The smalltalk code will take me a while to repackage as I'll > want to test it fairly carefully, and my time is very scattered (this is > my hobby, but lots of family demands :-)). > > > As a side effect, once this has been fully integrated it will be > possible to get rid of at least some of the "#if Pharo" type > conditionals in the FilePlugin, allowing the code to be tidied up. > > I'll post another reply once I've got the plugin code in > smalltalkhub.com. > > > Thanks again, > Alistair > > > >> Dave >> >> >> > >> > I've been using this as my production environment for about 2 months now >> > on a linux 32 bit VM. Running the full test suite results in the same >> > set of test failing before and after applying the patch. >> > >> > I've also ran file related tests on linux 64 bit (run the Test Runner, >> > select all packages with "file" as part of the name and run all the >> > available tests) and the full test suite on Windows 32 bit. >> > >> > The summary is: >> > >> > 1. #isSymlink now works properly on Linux (and it should also work on >> > MacOS and BSD). >> > 2. The list of file attributes available from FileReference now is: >> > #accessTime (new) >> > #changeTime (new) >> > #creationTime >> > #deviceId (new) >> > #exists >> > #gid (new) >> > #inode (new) >> > #isBlock (new) >> > #isCharacter (new) >> > #isDirectory >> > #isExecutable (new) >> > #isFIFO (new) >> > #isFile >> > #isReadable >> > #isRegular (new) >> > #isSocket (new) >> > #isSymlink (works) >> > #isWritable >> > #modificationTime >> > #numberOfHardLinks (new) >> > #permissions >> > #size >> > #targetFile (new) >> > #uid (new) >> > 3. FileReference>>exists is faster than before (well, at least on my >> > linux laptop). This is useful as it is called quite often. >> > 4. It is possible to retrieve symbolic link attributes, e.g. all the >> > attributes listed above plus the target path. >> > >> > >> > Given how similar MacOS and BSD are to linux, I assume that this will >> > all work without problem on those platforms (but it obviously needs to >> > be tested). >> > >> > As implied above, the changes are all backward compatible (except >> > the broken #isSymlink), although a couple deserve mention: >> > >> > 1. Obviously #isSymlink now answers correctly (previously it would only >> > answer correctly for a broken link). >> > 2. Requesting any of the attributes listed above (except #isSymlink) >> > will return the value of the target path. If the FileReference is to a >> > broken symbolic link, it will return the attributes of the symbolic >> > link (keeping existing behaviour). >> > 3. The attributes of a symbolic link can be retrieved using >> > FileReference>>symlinkAttributes. >> > >> > Overall, performance is slightly better than before. Code that >> > needs to access multiple attributes and is written to take advantage of >> > the new behaviour will see significant performance improvements. >> > >> > >> > If you've got this far and forgotten the original question :-) >> > >> > Can someone point me to how to submit a new VM plugin? >> > >> > >> > Thanks, >> > Alistair >

July 25, 2017