- Pharo-dev - lists.pharo.org

WorkingSession log

by Sven Van Caekenberghe

Hi, I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: 1ms startup:true a ClassSessionHandler(ProcessorScheduler) 1ms startup:true a ClassSessionHandler(OSPlatform) 6ms startup:true a ClassSessionHandler(ExternalObject) 1ms startup:true a ClassSessionHandler(DiskStore) 5ms startup:true a ClassSessionHandler(SmalltalkImage) 9ms startup:true a ClassSessionHandler(DisplayScreen) 1ms startup:true a ClassSessionHandler(Cursor) 41ms startup:true a ClassSessionHandler(FT2Handle) 238ms startup:true a ClassSessionHandler(FreeTypeSettings) 1ms startup:true a ClassSessionHandler(WorldMorph) 14ms startup:true a ClassSessionHandler(OmSessionStore) For a total of 318ms I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. Sven PS: The code of SessionManager/WorkingSession was very readable, well done Christophe !

July 27, 2017

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

by Tudor Girba

Hi, Athens is part of Pharo and the priority is to make it work for Pharo. If there are other users of such a core technology, they should be the ones adapting. @Alex Syrel: could you please take a look at the latest commits from Athens and clarify their state? Cheers, Doru > On Jul 26, 2017, at 9:44 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > 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 >>>> >>>> >>>> >>> >> > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

July 27, 2017

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

by Serge Stinckwich

On Thu, Jul 27, 2017 at 10:04 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > If you read carefully what I wrote, I was wondering what were these small > bugs fixes... and if P6.1 would be helpful for the drgeo problems: a list > of bugs with links to the bug tracker will have been enough. > > âI guess this will easier for Pharo 7. We can group PR with milestones on github in order to built nice list when release new version. I guess something similar could be done on fogbugz. â > Hilaire > > > Le 26/07/2017 Ã 16:25, Stephane Ducasse a Ã©crit : > >> People are nice and trying to help now everybody has its own agenda >> and we set these "rules" >> > > -- > Dr. Geo > http://drgeo.eu > > > > -- Serge Stinckwich UCN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

July 27, 2017

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

by Hilaire

If you read carefully what I wrote, I was wondering what were these small bugs fixes... and if P6.1 would be helpful for the drgeo problems: a list of bugs with links to the bug tracker will have been enough. Hilaire Le 26/07/2017 Ã 16:25, Stephane Ducasse a Ã©crit : > People are nice and trying to help now everybody has its own agenda > and we set these "rules" -- Dr. Geo http://drgeo.eu

July 27, 2017

Re: [Pharo-dev] GTInspector and sorting in dictionaries

by Juraj Kubelka

Hi, > El 26-07-2017, a las 20:28, Holger Freyther <holger(a)freyther.de> escribiÃ³: > > 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? By default, Glamour framework sorts string representations of displayed data. > > 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? You cannot send #< message to any object, e.g. Object new < Object new. I think it would be necessary to introduce a new method to Object (or ProtoObject) to deal with your scenario in a polymorphic way. > > 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..)? If I need a customized Inspector views, I usually subclass a collection class. In your case, it would be: Dictionary subclass: NumberKeyedDictionary â¦ or something like that â¦ then you can change Glamour presentations (GTInspector extensions). > > cheers > holger Cheers, Juraj

July 27, 2017

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