- Pharo-dev - lists.pharo.org

Re: Array sum. is very slow

by John Brant

On Jan 6, 2022, at 4:35 PM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > No, it is an array of floats. The only integers in the test are in the indexes of the loops. > > Number random. "generates a float 0.8188008774329387" > > So in the randarray below it is an array of 28800 floats. > > It just felt so wrong to me that Python3 was so much faster. I don't care if Nim, Crystal, Julia are faster. But... > > > I am new to Iceberg and have never shared anything on Github so this is all new to me. I uploaded my language test so you can see what it does. It is a micro-benchmark. It does things that are not realistic in an app. But it does stress a language in areas important to my app. > > > https://github.com/jlhouchin/LanguageTestPharo > > > Let me know if there is anything else I can do to help solve this problem. > > I am a lone developer in my spare time. So my apologies for any ugly code. > Are you sure that you have the same algorithm in Python? You are calling sum and average inside the loop where you are modifying the array: 1 to: nsize do: [ :j || n | n := narray at: j. narray at: j put: (self loop1calc: i j: j n: n). nsum := narray sum. navg := narray average ] As a result, you are calculating the sum of the 28,800 size array 28,800 times (plus another 28,800 times for the average). If I write a similar loop in Python, it looks like it would take almost 9 minutes on my machine without using numpy to calculate the sum. The Pharo code takes ~40 seconds. If this is really how the code should be, then I would change it to not call sum twice (once for sum and once in average). This will almost result in a 2x speedup. You could also modify the algorithm to update the nsum value in the loop instead of summing the array each time. I think the updating would require <120,000 math ops vs the >1.6 billion that you are performing. John Brant

Jan. 7, 2022

Re: Array sum. is very slow

by Jimmie Houchin

No, it is an array of floats. The only integers in the test are in the indexes of the loops. Number random. "generates a floatÂ 0.8188008774329387" So in the randarray below it is an array of 28800 floats. It just felt so wrong to me that Python3 was so much faster. I don't care if Nim, Crystal, Julia are faster. But... I am new to Iceberg and have never shared anything on Github so this is all new to me. I uploaded my language test so you can see what it does. It is a micro-benchmark. It does things that are not realistic in an app. But it does stress a language in areas important to my app. https://github.com/jlhouchin/LanguageTestPharo Let me know if there is anything else I can do to help solve this problem. I am a lone developer in my spare time. So my apologies for any ugly code. Thanks for your help. Jimmie On 1/6/22 15:07, Guillermo Polito wrote: > Hi Jummie, > > Is it possible that your program is computing a lot of **very** large integers? > > Iâm just trying the following with small numbers, and I donât see the issue. #sum executes on a 28k large collection around 20 million times per second on my old 2015 i5. > > a := (1 to: 28000). > [a sum] bench "'20256552.490 per secondâ" > > If you could share with us more data, we could take a look. > Now iâm curious. > > Thanks, > G > >> El 6 ene 2022, a las 21:37, Jimmie Houchin <jlhouchin(a)gmail.com> escribiÃ³: >> >> I have written a micro benchmark which stresses a language in areas which are crucial to my application. >> >> I have written this micro benchmark in Pharo, Crystal, Nim, Python, PicoLisp, C, C++, Java and Julia. >> >> On my i7 laptop Julia completes it in about 1 minute and 15 seconds, amazing magic they have done. >> >> Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. Pharo takes over 2 hours. :( >> >> In my benchmarks if I comment out the sum and average of the array. It completes in 3.5 seconds. >> And when I sum the array it gives the correct results. So I can verify its validity. >> >> To illustrate below is some sample code of what I am doing. I iterate over the array and do calculations on each value of the array and update the array and sum and average at each value simple to stress array access and sum and average. >> >> 28800 is simply derived from time series one minute values for 5 days, 4 weeks. >> >> randarray := Array new: 28800. >> >> 1 to: randarray size do: [ :i | randarray at: i put: Number random ]. >> >> randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations here." randarray sum. randarray average ]] timeToRun. >> >> randarrayttr. "0:00:00:36.135" >> >> >> I do 2 loops with 100 iterations each. >> >> randarrayttr * 200. "0:02:00:27" >> >> >> I learned early on in this adventure when dealing with compiled languages that if you donât do a lot, the test may not last long enough to give any times. >> >> Pharo is my preference. But this is an awful big gap in performance. When doing backtesting this is huge. Does my backtest take minutes, hours or days? >> >> I am not a computer scientist nor expert in Pharo or Smalltalk. So I do not know if there is anything which can improve this. >> >> >> However I have played around with several experiments of my #sum: method. >> >> This implementation reduces the time on the above randarray in half. >> >> sum: col >> | sum | >> sum := 0. >> 1 to: col size do: [ :i | >> sum := sum + (col at: i) ]. >> ^ sum >> >> randarrayttr2 := [ 1 to: randarray size do: [ :i | "other calculations here." >> ltsa sum: randarray. ltsa sum: randarray ]] timeToRun. >> randarrayttr2. "0:00:00:18.563" >> >> And this one reduces it a little more. >> >> sum10: col >> | sum | >> sum := 0. >> 1 to: ((col size quo: 10) * 10) by: 10 do: [ :i | >> sum := sum + (col at: i) + (col at: (i + 1)) + (col at: (i + 2)) + (col at: (i + 3)) + (col at: (i + 4)) >> + (col at: (i + 5)) + (col at: (i + 6)) + (col at: (i + 7)) + (col at: (i + 8)) + (col at: (i + 9))]. >> ((col size quo: 10) * 10 + 1) to: col size do: [ :i | >> sum := sum + (col at: i)]. >> ^ sum >> >> randarrayttr3 := [ 1 to: randarray size do: [ :i | "other calculations here." >> ltsa sum10: randarray. ltsa sum10: randarray ]] timeToRun. >> randarrayttr3. "0:00:00:14.592" >> >> It closes the gap with plain Python3 no numpy. But that is a pretty low standard. >> >> Any ideas, thoughts, wisdom, directions to pursue. >> >> Thanks >> >> Jimmie >>

Jan. 6, 2022

Re: Array sum. is very slow

by Guillermo Polito

Hi Jummie, Is it possible that your program is computing a lot of **very** large integers? Iâm just trying the following with small numbers, and I donât see the issue. #sum executes on a 28k large collection around 20 million times per second on my old 2015 i5. a := (1 to: 28000). [a sum] bench "'20256552.490 per secondâ" If you could share with us more data, we could take a look. Now iâm curious. Thanks, G > El 6 ene 2022, a las 21:37, Jimmie Houchin <jlhouchin(a)gmail.com> escribiÃ³: > > I have written a micro benchmark which stresses a language in areas which are crucial to my application. > > I have written this micro benchmark in Pharo, Crystal, Nim, Python, PicoLisp, C, C++, Java and Julia. > > On my i7 laptop Julia completes it in about 1 minute and 15 seconds, amazing magic they have done. > > Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. Pharo takes over 2 hours. :( > > In my benchmarks if I comment out the sum and average of the array. It completes in 3.5 seconds. > And when I sum the array it gives the correct results. So I can verify its validity. > > To illustrate below is some sample code of what I am doing. I iterate over the array and do calculations on each value of the array and update the array and sum and average at each value simple to stress array access and sum and average. > > 28800 is simply derived from time series one minute values for 5 days, 4 weeks. > > randarray := Array new: 28800. > > 1 to: randarray size do: [ :i | randarray at: i put: Number random ]. > > randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations here." randarray sum. randarray average ]] timeToRun. > > randarrayttr. "0:00:00:36.135" > > > I do 2 loops with 100 iterations each. > > randarrayttr * 200. "0:02:00:27" > > > I learned early on in this adventure when dealing with compiled languages that if you donât do a lot, the test may not last long enough to give any times. > > Pharo is my preference. But this is an awful big gap in performance. When doing backtesting this is huge. Does my backtest take minutes, hours or days? > > I am not a computer scientist nor expert in Pharo or Smalltalk. So I do not know if there is anything which can improve this. > > > However I have played around with several experiments of my #sum: method. > > This implementation reduces the time on the above randarray in half. > > sum: col > | sum | > sum := 0. > 1 to: col size do: [ :i | > sum := sum + (col at: i) ]. > ^ sum > > randarrayttr2 := [ 1 to: randarray size do: [ :i | "other calculations here." > ltsa sum: randarray. ltsa sum: randarray ]] timeToRun. > randarrayttr2. "0:00:00:18.563" > > And this one reduces it a little more. > > sum10: col > | sum | > sum := 0. > 1 to: ((col size quo: 10) * 10) by: 10 do: [ :i | > sum := sum + (col at: i) + (col at: (i + 1)) + (col at: (i + 2)) + (col at: (i + 3)) + (col at: (i + 4)) > + (col at: (i + 5)) + (col at: (i + 6)) + (col at: (i + 7)) + (col at: (i + 8)) + (col at: (i + 9))]. > ((col size quo: 10) * 10 + 1) to: col size do: [ :i | > sum := sum + (col at: i)]. > ^ sum > > randarrayttr3 := [ 1 to: randarray size do: [ :i | "other calculations here." > ltsa sum10: randarray. ltsa sum10: randarray ]] timeToRun. > randarrayttr3. "0:00:00:14.592" > > It closes the gap with plain Python3 no numpy. But that is a pretty low standard. > > Any ideas, thoughts, wisdom, directions to pursue. > > Thanks > > Jimmie >

Jan. 6, 2022

Array sum. is very slow

by Jimmie Houchin

I have written a micro benchmark which stresses a language in areas which are crucial to my application. I have written this micro benchmark in Pharo, Crystal, Nim, Python, PicoLisp, C, C++, Java and Julia. On my i7 laptop Julia completes it in about 1 minute and 15 seconds, amazing magic they have done. Crystal and Nim do it in about 5 minutes. Python in about 25 minutes. Pharo takes over 2 hours. :( In my benchmarks if I comment out the sum and average of the array. It completes in 3.5 seconds. And when I sum the array it gives the correct results. So I can verify its validity. To illustrate below is some sample code of what I am doing. I iterate over the array and do calculations on each value of the array and update the array and sum and average at each value simple to stress array access and sum and average. 28800 is simply derived from time series one minute values for 5 days, 4 weeks. randarray := Array new: 28800. 1 to: randarray size do: [ :i | randarray at: i put: Number random ]. randarrayttr := [ 1 to: randarray size do: [ :i | "other calculations here." randarray sum. randarray average ]] timeToRun. randarrayttr. "0:00:00:36.135" I do 2 loops with 100 iterations each. randarrayttr * 200. "0:02:00:27" I learned early on in this adventure when dealing with compiled languages that if you donât do a lot, the test may not last long enough to give any times. Pharo is my preference. But this is an awful big gap in performance. When doing backtesting this is huge. Does my backtest take minutes, hours or days? I am not a computer scientist nor expert in Pharo or Smalltalk. So I do not know if there is anything which can improve this. However I have played around with several experiments of my #sum: method. This implementation reduces the time on the above randarray in half. sum: col | sum | sum := 0. 1 to: col size do: [ :i | Â Â Â Â sum := sum + (col at: i) ]. ^ sum randarrayttr2 := [ 1 to: randarray size do: [ :i | "other calculations here." Â Â Â ltsa sum: randarray. ltsa sum: randarray ]] timeToRun. randarrayttr2. "0:00:00:18.563" And this one reduces it a little more. sum10: col | sum | sum := 0. 1 to: ((col size quo: 10) * 10) by: 10 do: [ :i | Â Â Â Â sum := sum + (col at: i) + (col at: (i + 1)) + (col at: (i + 2)) + (col at: (i + 3)) + (col at: (i + 4)) Â Â Â Â Â Â Â Â + (col at: (i + 5)) + (col at: (i + 6)) + (col at: (i + 7)) + (col at: (i + 8)) + (col at: (i + 9))]. ((col size quo: 10) * 10 + 1) to: col size do: [ :i | Â Â Â Â sum := sum + (col at: i)]. ^ sum randarrayttr3 := [ 1 to: randarray size do: [ :i | "other calculations here." Â Â Â ltsa sum10: randarray. ltsa sum10: randarray ]] timeToRun. randarrayttr3. "0:00:00:14.592" It closes the gap with plain Python3 no numpy. But that is a pretty low standard. Any ideas, thoughts, wisdom, directions to pursue. Thanks Jimmie

Jan. 6, 2022

Sockets not working under heavy VM load?

by Pavel Krivanek

Hi, we have some performance issues with Glorp over P3 and, after some investigation, I have a theory that could explain it. And I would like to know your opinion if it is correct. To reproduce this issue, you can try something easy. Just create a process with normal or higher priority that will try to read something from a socket. And, in parallel, do in a separate thread an operation that takes all the processor time for several seconds. ```` [ 5 seconds wait. Time now traceCr. ZnClient new url: 'https://www.google.com'; get. Time now traceCr. ] forkAt: 60. [1000 timesRepeat: [ 10000 factorial ] ] timeToRun ```` (you may try a different safe server address) The processes run in parallel until the time when the first process tries to obtain data from the socket. Then it hangs and waits until finishing of the second process. My theory is that the VM socket plugin is able to receive incoming data from the connection and save it into the buffer. In the meantime, the reading process is waiting on the socket semaphore. But it looks like the plugin is not able to release the semaphore while the VM is actually doing something. It needs to wait until the VM has nothing useful to do, and then it is finally able to release the semaphores so Pharo processes are resumed and can start to read. Is my theory right? Cheers, -- Pavel

Dec. 29, 2021

Re: FileDoesNotExistException - FileBrowser opening on Mac M1

by stephane ducasse

Hi Thanks for the report. Did you enter a bug report for the M1 case? Do you have a reproducible case? May be Apple changed some file info under our feet but probably that the tool should not be blindy trying to access files. S > On 23 Dec 2021, at 17:56, Stewart MacLean <stewmaclean(a)gmail.com> wrote: > > Hi All, > > This is my first post! Sadly it is to report an issue with the FileBrowser on the Mac M1. > > I am encountering this exception - FileDoesNotExistException. > > These are the culprits: > > <image.png> > > I have seen a similar error reported on Windows. Looks like Pharo can't access the attributes of these files? https://github.com/pharo-project/pharo/issues/3571 <https://github.com/pharo-project/pharo/issues/3571> > > I'm exploring Pharo with a view to migrating my VisualWorks project of many years, as support for M1 looks like it might be a way off, so not off to a good start! > > I managed to work around it, by deleting these two files (not from the disk!) in the debugger, before it tried to fetch the attributes. Interestingly, when in the debugger it showed N/A and 0 for the attributes, as these are system files I'm guessing. > > Thanks, > > Stewart > > ==================================================================== > Pharo 9.0.0 > Build information: Pharo-9.0.0+build.1573.sha.0e09d756fc99383cbb498565200d9e5e9841ce11 (64 Bit) > > Mac Mini M1 (2020) > Monterey 12.0.1 > > File class>>signalError:for: > File class>>primFileAttribute:number: > File class>>fileAttribute:number: > MacStore(DiskStore)>>sizeOf: > FileSystem>>sizeOf: > FileReference>>size > FileReference(AbstractFileReference)>>humanReadableSize > FileListGridNode>>fileSize > [:node :cont | node perform: self rowMorphGetSelector] in MorphTreeColumn>>rowMorphGetterBlock in Block: [:node :cont | node perform: self rowMorphGetSelec...etc... > MorphTreeColumn>>rowMorphFor: > [:col | | v | > v := col rowMorphFor: complexContents. > controls add: v. > col -> v] in MorphTreeNodeMorph>>buildRowMorph in Block: [:col | | v |... > OrderedCollection>>collect: > MorphTreeNodeMorph>>buildRowMorph > MorphTreeNodeMorph>>initRow > MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: > [:item :idx | > priorMorph := self indentingItemClass new > initWithContents: item > prior: priorMorph > forList: self > indentLevel: newIndent. > firstAddition > ifNil: [firstAddition := priorMorph]. > morphList add: priorMorph. > "Was this row expanded ? if true -> expand it > again " > ((item hasEquivalentIn: expandedItems) > or: [priorMorph isExpanded]) > ifTrue: [priorMorph isExpanded: true. > priorMorph > addChildrenForList: self > addingTo: morphList > withExpandedItems: expandedItems]] in MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [:item :idx | ... > Array(SequenceableCollection)>>withIndexDo: > Array(Collection)>>doWithIndex: > MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: > MorphTreeMorph>>addSubmorphsFromNodeList:previouslyExpanded: > MorphTreeMorph>>addSubmorphsFromNodeList > MorphTreeMorph>>buildContents > FileListGrid>>treeMorph > FileList>>morphicGrid > FileList>>grid > FileList>>updateFileList > FileList>>reference: > FileList>>directory: > FileList>>initialize > FileList class(Behavior)>>new > > On Thu, Dec 23, 2021 at 4:23 PM Stewart MacLean <stewart(a)xtra.co.nz <mailto:stewart@xtra.co.nz>> wrote: > Hi All, > > This is my first post! Sadly it is to enquire about an issue with the FileBrowser on the Mac M1. > > I am encountering this exception - FileDoesNotExistException. > > I appears to be opening on just two files: > > <image.png> > > I have seen a similar error reported on Windows. Looks like Pharo can't access the attributes of these files? https://github.com/pharo-project/pharo/issues/3571 <https://github.com/pharo-project/pharo/issues/3571> > > I'm exploring Pharo with a view to migrating my VisualWorks project of many years, as support for M1 looks like it might be a way off, so not a good start! > > Any help appreciated. > > Thanks, > > Stewart > > ==================================================================== > Pharo 9.0.0 > Build information: Pharo-9.0.0+build.1573.sha.0e09d756fc99383cbb498565200d9e5e9841ce11 (64 Bit) > > Mac Mini M1 (2020) > Monterey 12.0.1 > > File class>>signalError:for: > File class>>primFileAttribute:number: > File class>>fileAttribute:number: > MacStore(DiskStore)>>sizeOf: > FileSystem>>sizeOf: > FileReference>>size > FileReference(AbstractFileReference)>>humanReadableSize > FileListGridNode>>fileSize > [:node :cont | node perform: self rowMorphGetSelector] in MorphTreeColumn>>rowMorphGetterBlock in Block: [:node :cont | node perform: self rowMorphGetSelec...etc... > MorphTreeColumn>>rowMorphFor: > [:col | | v | > v := col rowMorphFor: complexContents. > controls add: v. > col -> v] in MorphTreeNodeMorph>>buildRowMorph in Block: [:col | | v |... > OrderedCollection>>collect: > MorphTreeNodeMorph>>buildRowMorph > MorphTreeNodeMorph>>initRow > MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: > [:item :idx | > priorMorph := self indentingItemClass new > initWithContents: item > prior: priorMorph > forList: self > indentLevel: newIndent. > firstAddition > ifNil: [firstAddition := priorMorph]. > morphList add: priorMorph. > "Was this row expanded ? if true -> expand it > again " > ((item hasEquivalentIn: expandedItems) > or: [priorMorph isExpanded]) > ifTrue: [priorMorph isExpanded: true. > priorMorph > addChildrenForList: self > addingTo: morphList > withExpandedItems: expandedItems]] in MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [:item :idx | ... > Array(SequenceableCollection)>>withIndexDo: > Array(Collection)>>doWithIndex: > MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: > MorphTreeMorph>>addSubmorphsFromNodeList:previouslyExpanded: > MorphTreeMorph>>addSubmorphsFromNodeList > MorphTreeMorph>>buildContents > FileListGrid>>treeMorph > FileList>>morphicGrid > FileList>>grid > FileList>>updateFileList > FileList>>reference: > FileList>>directory: > FileList>>initialize > FileList class(Behavior)>>new > >

Dec. 26, 2021

CLAP - how to get instance of command without executing it

by bajger＠gmail.com

Hi Pharoers! I have following problem in CLAP and would be glad to get your guidance: I have following method on command class (sub-class of ClapApplication):\ `PhLImageKillCliCommand>>osShellCmdString` `(arguments at: #all) value ` ` ifTrue: [ ^ (self killImageCmdStringFrom: nil) ]. ` `^ self killImageCmdStringFrom: self imageName` And I want to implement unit test, that would test expected output of this method. As you can see, implementation is dependent on arguments attribute #all. And here is a problem in unit test: `testOsShellCmdString`\ `| killCliCommand aMatch| aMatch := (context arguments: #('launcher' 'image' 'kill' '--all')) match. killCliCommand := PhLImageKillCliCommand new. killCliCommand setArguments: aMatch.` `self assert: killCliCommand osShellCmdString equals: ''.` This doesn't work, since `arguments at: #all` gives NotYetImplemented exception. So I don't know, how to "wire" toghether instance of command (without executing it) and needed arguments (a match). Any advice on this? ![ObrÃ¡zek](https://media.discordapp.net/attachments/819245127310114886/922498381358723123/unknown.png)

Dec. 25, 2021

Re: FileDoesNotExistException - FileBrowser opening on Mac M1

by Stewart MacLean

Hi All, This is my first post! Sadly it is to report an issue with the FileBrowser on the Mac M1. I am encountering this exception - FileDoesNotExistException. These are the culprits: [image: image.png] I have seen a similar error reported on Windows. Looks like Pharo can't access the attributes of these files? https://github.com/pharo-project/pharo/issues/3571 I'm exploring Pharo with a view to migrating my VisualWorks project of many years, as support for M1 looks like it might be a way off, so not off to a good start! I managed to work around it, by deleting these two files (not from the disk!) in the debugger, before it tried to fetch the attributes. Interestingly, when in the debugger it showed N/A and 0 for the attributes, as these are system files I'm guessing. Thanks, Stewart ==================================================================== Pharo 9.0.0 Build information: Pharo-9.0.0+build.1573.sha.0e09d756fc99383cbb498565200d9e5e9841ce11 (64 Bit) Mac Mini M1 (2020) Monterey 12.0.1 File class>>signalError:for: File class>>primFileAttribute:number: File class>>fileAttribute:number: MacStore(DiskStore)>>sizeOf: FileSystem>>sizeOf: FileReference>>size FileReference(AbstractFileReference)>>humanReadableSize FileListGridNode>>fileSize [:node :cont | node perform: self rowMorphGetSelector] in MorphTreeColumn>>rowMorphGetterBlock in Block: [:node :cont | node perform: self rowMorphGetSelec...etc... MorphTreeColumn>>rowMorphFor: [:col | | v | v := col rowMorphFor: complexContents. controls add: v. col -> v] in MorphTreeNodeMorph>>buildRowMorph in Block: [:col | | v |... OrderedCollection>>collect: MorphTreeNodeMorph>>buildRowMorph MorphTreeNodeMorph>>initRow MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: [:item :idx | priorMorph := self indentingItemClass new initWithContents: item prior: priorMorph forList: self indentLevel: newIndent. firstAddition ifNil: [firstAddition := priorMorph]. morphList add: priorMorph. "Was this row expanded ? if true -> expand it again " ((item hasEquivalentIn: expandedItems) or: [priorMorph isExpanded]) ifTrue: [priorMorph isExpanded: true. priorMorph addChildrenForList: self addingTo: morphList withExpandedItems: expandedItems]] in MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: in Block: [:item :idx | ... Array(SequenceableCollection)>>withIndexDo: Array(Collection)>>doWithIndex: MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: MorphTreeMorph>>addSubmorphsFromNodeList:previouslyExpanded: MorphTreeMorph>>addSubmorphsFromNodeList MorphTreeMorph>>buildContents FileListGrid>>treeMorph FileList>>morphicGrid FileList>>grid FileList>>updateFileList FileList>>reference: FileList>>directory: FileList>>initialize FileList class(Behavior)>>new On Thu, Dec 23, 2021 at 4:23 PM Stewart MacLean <stewart(a)xtra.co.nz> wrote: > Hi All, > > This is my first post! Sadly it is to enquire about an issue with the > FileBrowser on the Mac M1. > > I am encountering this exception - FileDoesNotExistException. > > I appears to be opening on just two files: > > [image: image.png] > > I have seen a similar error reported on Windows. Looks like Pharo can't > access the attributes of these files? > https://github.com/pharo-project/pharo/issues/3571 > > I'm exploring Pharo with a view to migrating my VisualWorks project of > many years, as support for M1 looks like it might be a way off, so not a > good start! > > Any help appreciated. > > Thanks, > > Stewart > > ==================================================================== > Pharo 9.0.0 > Build information: > Pharo-9.0.0+build.1573.sha.0e09d756fc99383cbb498565200d9e5e9841ce11 (64 Bit) > > Mac Mini M1 (2020) > Monterey 12.0.1 > > File class>>signalError:for: > File class>>primFileAttribute:number: > File class>>fileAttribute:number: > MacStore(DiskStore)>>sizeOf: > FileSystem>>sizeOf: > FileReference>>size > FileReference(AbstractFileReference)>>humanReadableSize > FileListGridNode>>fileSize > [:node :cont | node perform: self rowMorphGetSelector] in > MorphTreeColumn>>rowMorphGetterBlock in Block: [:node :cont | node perform: > self rowMorphGetSelec...etc... > MorphTreeColumn>>rowMorphFor: > [:col | | v | > v := col rowMorphFor: complexContents. > controls add: v. > col -> v] in MorphTreeNodeMorph>>buildRowMorph in Block: [:col | | v |... > OrderedCollection>>collect: > MorphTreeNodeMorph>>buildRowMorph > MorphTreeNodeMorph>>initRow > MorphTreeNodeMorph>>initWithContents:prior:forList:indentLevel: > [:item :idx | > priorMorph := self indentingItemClass new > initWithContents: item > prior: priorMorph > forList: self > indentLevel: newIndent. > firstAddition > ifNil: [firstAddition := priorMorph]. > morphList add: priorMorph. > "Was this row expanded ? if true -> expand it > again " > ((item hasEquivalentIn: expandedItems) > or: [priorMorph isExpanded]) > ifTrue: [priorMorph isExpanded: true. > priorMorph > addChildrenForList: self > addingTo: morphList > withExpandedItems: expandedItems]] in > MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: in Block: > [:item :idx | ... > Array(SequenceableCollection)>>withIndexDo: > Array(Collection)>>doWithIndex: > MorphTreeMorph>>addMorphsTo:from:withExpandedItems:atLevel: > MorphTreeMorph>>addSubmorphsFromNodeList:previouslyExpanded: > MorphTreeMorph>>addSubmorphsFromNodeList > MorphTreeMorph>>buildContents > FileListGrid>>treeMorph > FileList>>morphicGrid > FileList>>grid > FileList>>updateFileList > FileList>>reference: > FileList>>directory: > FileList>>initialize > FileList class(Behavior)>>new > > >

Dec. 23, 2021

Re: pharo9 tools moldability

by Esteban Lorenzano

you have also this : https://github.com/pharo-spec/smalltodo-example/blob/master/SmallTODO-Tutor… Esteban On Dec 19 2021, at 8:37 pm, Danil Osipchuk <danil.osipchuk(a)gmail.com> wrote: > Sebastian, yes, this is exactly kind of writeups I was asking for -- thanks > > regards, > Danil > > > > Ð²Ñ, 19 Ð´ÐµÐº. 2021 Ð³. Ð² 20:19, Sebastian Jordan Montano <sebastian.jordan(a)inria.fr (mailto:sebastian.jordan@inria.fr)>: > > This may interest you: > > > > > > https://modularmoose.org/2021/05/04/how-to-build-a-new-moose-tool.html > > > > > De: "Danil Osipchuk" <danil.osipchuk(a)gmail.com (mailto:danil.osipchuk@gmail.com)> > > > Ã: "Pharo Development List" <pharo-dev(a)lists.pharo.org (mailto:pharo-dev@lists.pharo.org)> > > > EnvoyÃ©: Samedi 18 DÃ©cembre 2021 15:06:33 > > > Objet: [Pharo-dev] pharo9 tools moldability > > > > > > > Dear all, > > > > > > Being a long time smalltalk user (meaning I'm crafting tools for my own usage for domains I'm working with) I always relied upon the environment itself to interact with models to spare time creating user interfaces. Besides plain inspectors I used metafacilities where possible -- seaside, then omnibrowser and lately glamour toolkit in pharo8. > > > Now it seems the glamourous core is not part of pharo9 anymore. Meanwhile pharo9 looks increasingly neat and I would like to make a transition but having tools in pharo8 holds me back. > > > I would be grateful for any pointers to help me to get started with the moldable inspectors pharo9 - papers, talks, online discussions, etc. I can likely figure it out on my own, but having an overall understanding of the approach concept would save an effort and shorten the trial and error phase. > > > (maybe I'm overcomplicating it and just having browsed around inspector code pragmas is enough to get started) > > > > > > > > > > > > > > > regards, > > > Danil > > > > > > > > > > > > >

Dec. 20, 2021

Re: pharo9 tools moldability

by Danil Osipchuk

Sebastian, yes, this is exactly kind of writeups I was asking for -- thanks regards, Danil Ð²Ñ, 19 Ð´ÐµÐº. 2021 Ð³. Ð² 20:19, Sebastian Jordan Montano < sebastian.jordan(a)inria.fr>: > This may interest you: > > https://modularmoose.org/2021/05/04/how-to-build-a-new-moose-tool.html > > ------------------------------ > > *De: *"Danil Osipchuk" <danil.osipchuk(a)gmail.com> > *Ã: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *EnvoyÃ©: *Samedi 18 DÃ©cembre 2021 15:06:33 > *Objet: *[Pharo-dev] pharo9 tools moldability > > Dear all, > > Being a long time smalltalk user (meaning I'm crafting tools for my own > usage for domains I'm working with) I always relied upon the environment > itself to interact with models to spare time creating user interfaces. > Besides plain inspectors I used metafacilities where possible -- seaside, > then omnibrowser and lately glamour toolkit in pharo8. > > Now it seems the glamourous core is not part of pharo9 anymore. Meanwhile > pharo9 looks increasingly neat and I would like to make a transition but > having tools in pharo8 holds me back. > > I would be grateful for any pointers to help me to get started with the > moldable inspectors pharo9 - papers, talks, online discussions, etc. I can > likely figure it out on my own, but having an overall understanding of the > approach concept would save an effort and shorten the trial and error > phase. > (maybe I'm overcomplicating it and just having browsed around inspector > code pragmas is enough to get started) > > > > regards, > Danil > >

Dec. 19, 2021