- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Annotating instance variables

by Torsten Bergmann

Sept. 11, 2015

Re: [Pharo-dev] Annotating instance variables

by HernÃ¡n Morales Durand

Hi Marcus, Thanks for the answers. I am discovering Reflectivity, I just have a couple more questions if you don't mind: 2015-09-11 15:26 GMT-03:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 11 Sep 2015, at 20:05, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > > > I saw some interesting reflection progress in Pharo 5. I wonder if there > is a feature to rank instance variables. For example, from the browser I > want to assign a category "important" to an instance variable, or "possibly > useless", etc. for later refactorings. > > > > Is such thing "easily" possible now? There is API support from > Reflectivity maybe? > > > > The infrastructure is thereâ¦ we can annotate instance variables. > > (Point slotNamed: #x) propertyAt: #note put: 'useless'. > (Point slotNamed: #x) propertyAt: #note > > One could build a user interface around that. > > This is cool, I just hope the Nautilus plugin interface is stable by now then :) > Properties are not saved with monticello, though. They are like method > properties. So one would > need to build something on top... > > I don't know about MC model, but maybe extending MC to support properies/annotations could be a path? > Another idea would be to make a subclass of InstanceVariableSlot that > stores the note in a property but > it is actually part of the slot definition: > > Object subclass: #Point > slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. > #y } > classVariables: { } > category: 'Kernel-BasicObjects' > > As the note is part of the slot definition, it would be saved in > Monticello. > > It could be silly question but most of the time I wish to annotate while debugging, using that option would affect my debugged objec state? Cheers, HernÃ¡n > (unrelated: I still am tempted to just use the term âinstance variableâ > and get rid of the term Slot.. for the paper is was nice, but now? > Especially > as we have slot like first class ClassVars and Globals that nevertheless > are not slotsâ¦) > > Marcus > > > >

Sept. 11, 2015

Re: [Pharo-dev] [Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility

by David T. Lewis

Eliot, I agree. Indeed, even with an interpreter VM it has long been the case that a plugin compiled as 64 bit will not work on a VM compiled for 64 bit and vice versa. With the number of variations of 32/64, Spur/V3, and so forth, I don't think that this is a problem worth worrying about. Better to just be a aware that plugins are not readily interchangeable in those cases. Dave > Hi Chris, > > On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <brasspen(a)gmail.com> > wrote: > >> I had the idea that a plugin from one VM could be dragged into another >> VM's directory and that it could be used just by starting up the image. >> I've done a little experimenting and it seems more of an idea of a >> reality. >> The functionality is there, but VM developers over the years have not >> seen >> this as a priority. Typically plugins and their VMs are compiled >> together. >> Or a person adds one by recompiling a VM compilation rig they already >> have. >> > > The problems I see with this are > > a) a plugin compiled for Spur may not work with V3 or vice verse. The > issue is the header size of an object. Some plugins, but not all, use > this > define, and the header sizes between Spur and V3 are incompatible. > > b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't > work > with 32-bit VMs. Period. > > Now there are platform-level packaging technologies, such as fat binaries > on Mac OS X, that allow one to construct plugins that contain more than > one > binary. But this is a lot of work to build and maintain. > > So personally I wouldn't put much effort into this level of drag-and-drop > compatibility. Instead I'd put energy into good error messages so that > when plugins don't work the user can find out why, and that when the wrong > kind of plugin is used the VM doesn't just stumble along, maybe producing > incorrect results, but instead puts the plugin out with a comprehensible > complaint. > > Does this make sense? I know its a downer, but what you propose is, IMO, > not affordable given our resources. > > > And I must say, *this is a VM-DEV discussion, not a general purpose Squeak > discussion*, yes? > > As I had a rig for the Interpreter VM I decided to compile a plugin and > see >> if I could drag it around to other VM directories for use. Most times it >> didn't work. >> >> I compiled a TheUniversalAnswer plugin which returns 42. I moved it from >> a >> 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not >> use >> the squeak.sh start script. That is, I dragged so.vm-sound-null, >> so.TheUniversalAnswer and so.vm-display-X11 into the same directory as >> the >> VM binary. That worked. >> >> The only way to see the external plugins is with #listLoadedModules. >> But, >> irritatingly, modules are loaded as needed, so once you have proof of >> using >> the primitive from the plugin, yea, it will appear as a result of that >> Smalltalk listLoadedModules message. So, it's not that useful. >> >> I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 >> and >> 4.13.10-3268 without success. And the unload selectors #forgetModule: >> and >> unloadModule:, which both use primitive 571 don't appear to work on my >> Ubuntu 15.04. >> >> So, I don't know if a community of plugins passed around is in the >> offing. >> What I have learned is that many of the answers are in >> sqUnixExternalPrims.c. The issues are really where does the VM look for >> primitives and what does it do when it finds one. It appears to me, >> after >> reading both the non-Cog and Cog versions of that file, that this an >> interesting area poorly documented that VM developers alter in haste to >> get >> on to something else. >> >> It's pretty important stuff, though. Do you start the VM with the binary >> on the path? Do you use squeak.sh? Where is the VM looking for stuff. >> Where >> will FFI look for stuff. And so on. >> >> Chris >> >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Sept. 11, 2015

http://forum.world.st down?

by Dale Henrichs

http://downforeveryoneorjustme.com/forum.world.st

Sept. 11, 2015

Re: [Pharo-dev] Catalog does not update to include MessageFlowBrowser

by Torsten Bergmann

Hi Esteban, Unfortunately it is now completely broken, the JSON is not returned anymore: http://catalog.pharo.org/catalog/json gives MessageNotUnderstood: receiver of "repositoryUrl" is nil Can you have a look again? Thanks! Regards Torsten > Gesendet: Freitag, 11. September 2015 um 19:03 Uhr > Von: "Esteban Lorenzano" <estebanlm(a)gmail.com> > An: "Torsten Bergmann" <astares(a)gmx.de> > Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: Catalog does not update to include MessageFlowBrowser > > > > On 11 Sep 2015, at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > >> On 11 Sep 2015, at 16:29, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > >> Hi, > >> > >> ConfigurationOfMessageFlowBrowser is in http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo50 > >> for a week now but still not included in http://catalog.pharo.org > >> > >> According to the description there is a daily catalog job - but so far no results. It is not > >> included although the config includes the necessary catalog methods. > >> > >> - Is MetaRepoForPharo50 already recognized? > >> - Is it possible to "manually" trigger the catalog generation in case a new project is done? > >> > >> Anyone able to look into this? > > > > Iâll check the logs. > > fixed. > something went wrong when updating FFI (my fault :P) and then everything stop working. Of course there is a log who tells me that something went wrong, but I forget to check them :D > > cheers, > > > > > Esteban > > > >> > >> Thx > >> T. > > > >

Sept. 11, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Eliot Miranda

Hi Nicolai, On Fri, Sep 11, 2015 at 12:48 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-11 9:44 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > >> >> >> 2015-09-11 9:43 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> >>> >>> 2015-09-10 23:07 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> >>>> Hi Nicolai, >>>> >>>> On Thu, Sep 10, 2015 at 1:17 PM, Nicolai Hess <nicolaihess(a)web.de> >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> 2015-09-10 21:31 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>>> >>>>>> >>>>>> Hi Nicolai, >>>>>> >>>>>> I'm a bit concerned that this is creating drift with the >>>>>> "official" Cog source base at >>>>>> http://www.squeakvm.org/svn/squeak/branches/Cog. Long filename >>>>>> support for win32 was recently added by Marcel Taumel in May of this year. >>>>>> Are you tracking that? How can we keep the sources harmonized? >>>>>> >>>>> >>>>> Yes, I know, and I already asked on the ML if we can take that change >>>>> or >>>>> if it is not possible because we have already other changes (pharos >>>>> file plugin >>>>> provides addition attributes (the file permissions)). >>>>> >>>> >>>> Esteban and I just harmonized this. I'm (almost correctly) generating >>>> the plugin source such that one can define either PharoVM or not to chose >>>> between the different versions. I say "almost" because I'm currently >>>> spitting out >>>> >>>> #define PharoVM 0 >>>> ... >>>> #if PharoVM >>>> >>>> instead of >>>> >>>> #if !defined(PharoVM) >>>> # define PharoVM 0 >>>> #endif >>>> ... >>>> #if PharoVM >>>> >>>> but I'll fix it v soon. >>>> >>> >>> OK, I'll try to copy marcels solution >>> >>> >>>> >>>> But I got no response, so I tried to adopt Marcels change. >>>>> >>>>> And I only found the change for sqWin32FilePrims.c, but missed the >>>>> other change >>>>> that is necessary in sqWin32Directory.c (and asked on the ML). In the >>>>> meantime Marcel added this but I could not find >>>>> the changed source, only an updated vm. >>>>> Is this change already comitted? >>>>> >>>> >>>> Yes, see >>>> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/vm/sqWin32D… >>>> >>> >>> Ah, good. Now (I must be blind, but) I can not see the other change, >>> shouldn't there >>> be a "plugins" folder in Cog/platforms/win32/? >>> Where are the changes to sqWin32FilePrims.c now? >>> >> >> Ok, found it. It is in the trunk branch :) >> > > > No, wait, now I am confused. The change to sqWin32FilePrims.c is only in > the trunk branch and the change to sqWin32Directory.c is > only in the Cog branch. What branch includes the solution for both > (sqWin32Directory.c and sqWin32FilePrims.c) and should be > used for a merge into pharos vm repository? > There are two "externals" in the Cog branch: X platforms/win32/plugins X platforms/Cross/plugins So http://www.squeakvm.org/svn/squeak/branches/Cog is the Cog repository, but http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/win32/plugins is in fact http://squeakvm.org/svn/squeak/trunk/platforms/win32/plugins and http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/plugins is in fact http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins OK? > > >> >> >> >>> >>> >>> >>> >>>> >>>> I'm sorry I didn't see your message. Did you ask on vm-dev? >>>> >>> >>> I am not sure, maybe I only send it in the squeak-dev list >>> >>> >>>> >>>> >>>> >>>>> I would love if someone else got this working. >>>>> >>>> >>>> :-) I hear you :-) >>>> >>>> >>>> >>>>> >>>>> nicolai >>>>> >>>>> >>>>> >>>>>> >>>>>> On Sun, Aug 23, 2015 at 4:44 AM, Nicolai Hess <nicolaihess(a)web.de> >>>>>> wrote: >>>>>> >>>>>>> For those who had problems with pharo on windows and github based >>>>>>> repositories, >>>>>>> I built a windows vm with support for long paths: >>>>>>> >>>>>>> >>>>>>> https://drive.google.com/file/d/0B8yEahnuIem2bmxwdzJuUXFxVGM/view?usp=shari… >>>>>>> >>>>>>> >>>>>>> For browsing directories with large paths (FileList or Inspect), >>>>>>> you may need one additional change in the image (But I am not really >>>>>>> sure about that) : >>>>>>> >>>>>>> DiskStore>>initialize >>>>>>> super initialize. >>>>>>> maxFileNameLength := Smalltalk vm maxFilenameLength ifNil: [ >>>>>>> 32767 ]. >>>>>>> >>>>>>> >>>>>>> please test and give feedback. >>>>>>> >>>>>>> This wasn't as easy as I thought, and I had to make some more changes >>>>>>> for the file permissions (the stat-functions don't work for files >>>>>>> with long paths). >>>>>>> Please test other file/folder operations. >>>>>>> >>>>>>> >>>>>>> nicolai >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> _,,,^..^,,,_ >>>>>> best, Eliot >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>>> >>> >> > > -- _,,,^..^,,,_ best, Eliot

Sept. 11, 2015

Re: [Pharo-dev] [squeak-dev] Criteria For Plugin Compatibility

by Eliot Miranda

Hi Chris, On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <brasspen(a)gmail.com> wrote: > I had the idea that a plugin from one VM could be dragged into another > VM's directory and that it could be used just by starting up the image. > I've done a little experimenting and it seems more of an idea of a reality. > The functionality is there, but VM developers over the years have not seen > this as a priority. Typically plugins and their VMs are compiled together. > Or a person adds one by recompiling a VM compilation rig they already have. > The problems I see with this are a) a plugin compiled for Spur may not work with V3 or vice verse. The issue is the header size of an object. Some plugins, but not all, use this define, and the header sizes between Spur and V3 are incompatible. b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't work with 32-bit VMs. Period. Now there are platform-level packaging technologies, such as fat binaries on Mac OS X, that allow one to construct plugins that contain more than one binary. But this is a lot of work to build and maintain. So personally I wouldn't put much effort into this level of drag-and-drop compatibility. Instead I'd put energy into good error messages so that when plugins don't work the user can find out why, and that when the wrong kind of plugin is used the VM doesn't just stumble along, maybe producing incorrect results, but instead puts the plugin out with a comprehensible complaint. Does this make sense? I know its a downer, but what you propose is, IMO, not affordable given our resources. And I must say, *this is a VM-DEV discussion, not a general purpose Squeak discussion*, yes? As I had a rig for the Interpreter VM I decided to compile a plugin and see > if I could drag it around to other VM directories for use. Most times it > didn't work. > > I compiled a TheUniversalAnswer plugin which returns 42. I moved it from a > 4.14.1-3430 VM to a 4.14.1-3414 VM. I could get it to work if I did not use > the squeak.sh start script. That is, I dragged so.vm-sound-null, > so.TheUniversalAnswer and so.vm-display-X11 into the same directory as the > VM binary. That worked. > > The only way to see the external plugins is with #listLoadedModules. But, > irritatingly, modules are loaded as needed, so once you have proof of using > the primitive from the plugin, yea, it will appear as a result of that > Smalltalk listLoadedModules message. So, it's not that useful. > > I dragged so.TheUniversalAnswer around to other VMs such as 4.0.3-2202 and > 4.13.10-3268 without success. And the unload selectors #forgetModule: and > unloadModule:, which both use primitive 571 don't appear to work on my > Ubuntu 15.04. > > So, I don't know if a community of plugins passed around is in the offing. > What I have learned is that many of the answers are in > sqUnixExternalPrims.c. The issues are really where does the VM look for > primitives and what does it do when it finds one. It appears to me, after > reading both the non-Cog and Cog versions of that file, that this an > interesting area poorly documented that VM developers alter in haste to get > on to something else. > > It's pretty important stuff, though. Do you start the VM with the binary > on the path? Do you use squeak.sh? Where is the VM looking for stuff. Where > will FFI look for stuff. And so on. > > Chris > > > > -- _,,,^..^,,,_ best, Eliot

Sept. 11, 2015

Re: [Pharo-dev] Annotating instance variables

by Marcus Denker

> On 11 Sep 2015, at 20:05, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > I saw some interesting reflection progress in Pharo 5. I wonder if there is a feature to rank instance variables. For example, from the browser I want to assign a category "important" to an instance variable, or "possibly useless", etc. for later refactorings. > > Is such thing "easily" possible now? There is API support from Reflectivity maybe? > The infrastructure is thereâ¦ we can annotate instance variables. (Point slotNamed: #x) propertyAt: #note put: 'useless'. (Point slotNamed: #x) propertyAt: #note One could build a user interface around that. Properties are not saved with monticello, though. They are like method properties. So one would need to build something on top... Another idea would be to make a subclass of InstanceVariableSlot that stores the note in a property but it is actually part of the slot definition: Object subclass: #Point slots: { #x => InstanceVariableWithNote note: âthis is uselessâ. #y } classVariables: { } category: 'Kernel-BasicObjects' As the note is part of the slot definition, it would be saved in Monticello. (unrelated: I still am tempted to just use the term âinstance variableâ and get rid of the term Slot.. for the paper is was nice, but now? Especially as we have slot like first class ClassVars and Globals that nevertheless are not slotsâ¦) Marcus

Sept. 11, 2015

Re: [Pharo-dev] Running a test method in Nautilus

by Alexandre Bergel

Thanks! That would be fantastic. Alexandre > On Sep 11, 2015, at 2:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 11 Sep 2015, at 16:37, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> I do experience the same thing with Guille today. >> Before, Nautilus ran twice the method for a failed test: one to get the status of the test and another one for the debugger. >> Maybe in Nautilus cleanup, it was removed. >> > Yes, I removed that double runnning.. this was not a good idea. Now it is much simpler. > > And yes, it is better to directly open the debugger when running single tests explicitly. > > I will fix it. > > Marcus > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2015

Re: [Pharo-dev] Running a test method in Nautilus

by Alexandre Bergel

Excellent! Thanks ! Works! Alexandre > On Sep 11, 2015, at 2:43 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> However, this indicates many closed issues. How can I filter out the close issues? >> > Yes, it is annoying that the default for the search is to search closed issues. > > You can, though, filter the search results. Press â+Refine Furtherâ, there are many things, amount them âOpen or Closedâ. Select Open. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2015