- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Cog+linux: external module not found

by Eliot Miranda

I'm definitely not interested in help from someone who flies off the handle like this. Plonk. On Mon, Jan 9, 2012 at 10:55 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Eliot, > > Whining - that's a bit much. In fact it is TOTALLY unjustified. > > Last year, I spent (end to end) months learning how to get away from > creating my own hacked vms - that's how I knew about ldconfig's behavior , > and have come to appreciate that Canonical got this one right. > > Recently, I spent hours running down why Cog fails to find properly > installed libraries on a major Linux platform. I'd say that's "pitching > in." It sure isn't whining!! > > Am I certain of all the details of what should happen and why? No. Am I > the best person to tell the vm to stop looking here/there/everywhere and > just use the module name as given? Certainly not. I *thought* you might > want to do that yourself, so it gets done properly. > > I also thought you might appreciate some help in debugging a problem. > Instead you tell me that I am an SOL whiner. Not good. > > Bill > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ > eliot.miranda(a)gmail.com] > *Sent:* Monday, January 09, 2012 1:34 PM > > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Cog+linux: external module not found > > > > On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <lewis(a)mail.msen.com>wrote: > >> On Sun, Jan 08, 2012 at 12:37:59AM +0000, Schwab,Wilhelm K wrote: >> > Eliot, >> > >> > SOL?? Is that really the message we want to send to current and >> *prospective* users? Canonical does something that makes sense from a >> security perspective (one needs root privileges to alter the ldconfig >> mapping, not to to use it). All the vm needs to do is request the >> #moduleName as given, and users of Pharo "SOL" as a result? >> > >> > Please reconsider. >> > >> > Bill >> > >> >> I think you are taking the response out of context. The actual statement >> was "Then you're SOL :) You'd need to write new support for Ubuntu." >> >> You might take that as a gentle suggestion to expend a bit of effort >> on it yourself. After all, it is open source, and Eliot is only one >> person. He can't do everything for everybody without a little help >> from the rest of us. >> > > quite. i don't even have an ubuntu VM, let alone the time to work on > it. Bill, instead of whining, pitch in, please. > > >> >> Dave >> >> >> > >> > >> > >> > ________________________________ >> > From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ >> eliot.miranda(a)gmail.com] >> > Sent: Saturday, January 07, 2012 6:38 PM >> > To: Pharo-project(a)lists.gforge.inria.fr >> > Subject: Re: [Pharo-project] Cog+linux: external module not found >> > >> > >> > >> > On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K < >> bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >> > Nick, >> > >> > Partial success. After a false start with getting output from strace >> (my fault), it showed me that the vm was looking a lot in the vm's >> directory. A symlink by the same name, allowed it to see the library. >> Clearly, this is not a fix, because one should not be forced to make links >> to any/every library on the system. However, it *was* nice to see the >> version string in an inspector :) >> > >> > Looking at the strace output (relevant parts below), it tries with >> prepending lib, appending .so, .so.dylib. It looks in the vm's directory, >> and in the root directory, not /usr/lib. >> > >> > It has been almost a year (based on a dated comment) since I last >> really strained my synapses on the workings of ldconfig. On my systems, it >> would tell one to look for the library as follows: >> > >> > ldconfig -p | grep Acces >> > libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so >> > >> > #moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My >> (and I use the term LOOSELY) understanding is that Ubuntu no longer uses >> LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as >> reported by ldconfig. The best explanation I have found is that the change >> was a security measure. >> > >> > Then you're SOL :) You'd need to write new support for Ubuntu. >> > >> > >> > How does one get ldconfig to "know" where something lives? Putting a >> .so file in /usr/lib (and perhaps other places too) and then running >> ldconfig as sudo appears to build a cache. Then ldconfig -p (anyone can >> run this) will show the map, and one can grep the result to find something >> specifc, as above. >> > >> > Putting files in /usr/lib is a pain for things under active >> development. A file can live anywhere if one puts a .conf file in >> /etc/ld.so.confd; the .conf files should contain paths to directories to be >> searched for .so files - or at least that's how it *appears* to work. Run >> ldconfig as sudo to refresh the mapping, and verify with ldconfig - p. >> > >> > The fix might be as simply as having the cog vm try passing the >> #moduleName to dlopen(). >> > >> > Nick, thanks for the nudge in a working direction. I will probably >> symlink another file and see if a mix of hardware and software will get >> closer to cooperating with me. >> > >> > Bill >> > >> >> >> > > > -- > best, > Eliot > > -- best, Eliot

Jan. 9, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Schwab,Wilhelm K

Eliot, Whining - that's a bit much. In fact it is TOTALLY unjustified. Last year, I spent (end to end) months learning how to get away from creating my own hacked vms - that's how I knew about ldconfig's behavior , and have come to appreciate that Canonical got this one right. Recently, I spent hours running down why Cog fails to find properly installed libraries on a major Linux platform. I'd say that's "pitching in." It sure isn't whining!! Am I certain of all the details of what should happen and why? No. Am I the best person to tell the vm to stop looking here/there/everywhere and just use the module name as given? Certainly not. I *thought* you might want to do that yourself, so it gets done properly. I also thought you might appreciate some help in debugging a problem. Instead you tell me that I am an SOL whiner. Not good. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Monday, January 09, 2012 1:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Cog+linux: external module not found On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <lewis(a)mail.msen.com<mailto:lewis@mail.msen.com>> wrote: On Sun, Jan 08, 2012 at 12:37:59AM +0000, Schwab,Wilhelm K wrote: > Eliot, > > SOL?? Is that really the message we want to send to current and *prospective* users? Canonical does something that makes sense from a security perspective (one needs root privileges to alter the ldconfig mapping, not to to use it). All the vm needs to do is request the #moduleName as given, and users of Pharo "SOL" as a result? > > Please reconsider. > > Bill > I think you are taking the response out of context. The actual statement was "Then you're SOL :) You'd need to write new support for Ubuntu." You might take that as a gentle suggestion to expend a bit of effort on it yourself. After all, it is open source, and Eliot is only one person. He can't do everything for everybody without a little help from the rest of us. quite. i don't even have an ubuntu VM, let alone the time to work on it. Bill, instead of whining, pitch in, please. Dave > > > > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] > Sent: Saturday, January 07, 2012 6:38 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] Cog+linux: external module not found > > > > On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote: > Nick, > > Partial success. After a false start with getting output from strace (my fault), it showed me that the vm was looking a lot in the vm's directory. A symlink by the same name, allowed it to see the library. Clearly, this is not a fix, because one should not be forced to make links to any/every library on the system. However, it *was* nice to see the version string in an inspector :) > > Looking at the strace output (relevant parts below), it tries with prepending lib, appending .so, .so.dylib. It looks in the vm's directory, and in the root directory, not /usr/lib. > > It has been almost a year (based on a dated comment) since I last really strained my synapses on the workings of ldconfig. On my systems, it would tell one to look for the library as follows: > > ldconfig -p | grep Acces > libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so > > #moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My (and I use the term LOOSELY) understanding is that Ubuntu no longer uses LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as reported by ldconfig. The best explanation I have found is that the change was a security measure. > > Then you're SOL :) You'd need to write new support for Ubuntu. > > > How does one get ldconfig to "know" where something lives? Putting a .so file in /usr/lib (and perhaps other places too) and then running ldconfig as sudo appears to build a cache. Then ldconfig -p (anyone can run this) will show the map, and one can grep the result to find something specifc, as above. > > Putting files in /usr/lib is a pain for things under active development. A file can live anywhere if one puts a .conf file in /etc/ld.so.confd; the .conf files should contain paths to directories to be searched for .so files - or at least that's how it *appears* to work. Run ldconfig as sudo to refresh the mapping, and verify with ldconfig - p. > > The fix might be as simply as having the cog vm try passing the #moduleName to dlopen(). > > Nick, thanks for the nudge in a working direction. I will probably symlink another file and see if a mix of hardware and software will get closer to cooperating with me. > > Bill > -- best, Eliot

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

On Mon, Jan 9, 2012 at 7:13 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 9 Jan 2012, Mariano Martinez Peck wrote: > > Hi Levente. Thanks for looking into the issue. I saw your code and there >> is >> something I don't understand. >> >> pointsTo: anObject >> "Answers true if the garbage collector would fail to collect anObject >> because I hold a reference to it, or false otherwise" >> >> (self instVarsInclude: anObject) >> ifTrue: [ >> self class isWeak ifFalse: [ ^true ]. >> 1 to: self class instSize do: [ :i | >> (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. >> ^false ] >> ifFalse: [ ^self class == anObject and: [ self class isCompact not >> ] ] >> >> >> I don't understand the loop of >> >> 1 to: self class instSize do: [ :i | >> (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. >> >> >> In which scenario can (self instVarsInclude: anObject) answer true, >> but the loop false? >> > > The scenario happens when the receiver has weak slots and the argument is > referenced from one of those weak slots, but not from the other slots. > > Ok, I see. And moreover, there has to be a GC in the middle, right? so..the scenario is "The scenario happens when the receiver has weak slots, the argument is referenced from one of those weak slots, but not from the other non-weak slots, and also when a GC runs between the invokation to #instVarsInclude: and the loop". is that correct? so that I will add this comment to the code ;) > > doesn't #instVarsInclude do exactly what you are doing there? >> > > Just partially. Since we have no information about which slots hold the > reference to the argument, therefore this loop must be "repeated". Ok, I see. > > > >> Anyway, I have integrated your changes in Pharo, but still, I have the >> same >> problem :( >> If I understand correctly, the following shouldn't fail, but it does. Here >> is the version of Squeak that fails. >> > > The assetion fails, because the indirection vector (the Array found by > PointerFinder) holds a reference to the object after the first assignment > to a. If you move the temporary inside the block or use an inlined loop > (e.g. #to:do: with literal block argument), then the assertion won't fail. > So this is just a normal (maybe surprising) reference to the object. > > Excellent. Now I got it. Thank you very much for your help Levente. Now PointerFinderTest are green :) > > Levente > > >> | a | >> 10 timesRepeat: [ >> a := Date new. >> Smalltalk garbageCollect. >> self assert: (PointerFinder pointersTo: a) isEmpty >> ] >> >> Thanks a lot, >> >> >> On Mon, Jan 9, 2012 at 2:40 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> On Sun, 8 Jan 2012, Mariano Martinez Peck wrote: >> >>> >>> What I don't understand is why in Squeak it does work. >>> >>>> >>>>> >>>>>> >>>>>> Because #pointsTo: is not used in Squeak (yet). As usual I dug deeper >>>>> than >>>>> I should have, so I'll publish a few changes soon. >>>>> >>>>> >>>>> Ok, you are right. Squeak #inboundPointersExcluding: is using >>>>> >>>> #instVarsInclude: rather than #pointsTo. And that solves the problem in >>>> Pharo as well. But still, I would like to understand why we get those >>>> method contexts with #pointsTo. >>>> >>>> >>> Because #pointsTo: is a normal message send, it even sends other methods, >>> so it will create contexts. >>> >>> >>> Thanks Levente for your help. If you find something let us know, I want >>> to >>> >>>> learn :) >>>> >>>> >>> I pushed my changes to the Squeak Inbox, which fully works around this >>> issue. The changes about weak references can simply be removed if you >>> don't >>> like them, the rest will just work without them. >>> >>> >>> Levente >>> >>> >>> Thanks >>>> >>>> >>>> >>>> Levente >>>>> >>>>> >>>>> Thanks in advance Levente! >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> it will create at least one new MethodContext which is not included >>>>>> in >>>>>> >>>>>> that list. >>>>>>> >>>>>>> >>>>>>> Levente >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Levente >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks again. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Levente >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Do you mean what I understand :)? that some tools compiled >>>>>>>>>>> methods? >>>>>>>>>>> :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Stef >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Mariano >>>>>>>>>>>>> >>>>>>>>>>>> http://marianopeck.wordpress.************com < >>>>>>>>>>>> http://marianopeck.wordpress. >>>>>>>>>>>> **** >>>>>>>>>>>> com <http://marianopeck.wordpress.********com< >>>>>>>>>>>> http://marianopeck.**** >>>>>>>>>>>> wordpress.com <http://marianopeck.wordpress.****com< >>>>>>>>>>>> http://marianopeck.**wordpress.com<http://marianopeck.wordpress.com> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.**********com < >>>>>>>>>> http://marianopeck.wordpress. >>>>>>>>>> **** >>>>>>>>>> com <http://marianopeck.wordpress.******com<http://marianopeck.** >>>>>>>>>> wordpress.com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.********com < >>>>>>>> http://marianopeck.wordpress. >>>>>>>> **** >>>>>>>> com <http://marianopeck.wordpress.****com<http://marianopeck.** >>>>>>>> wordpress.com <http://marianopeck.wordpress.com>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>> **** >>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>> >> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>> com <http://marianopeck.wordpress.com>> >>>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2012

Re: [Pharo-project] Cog+linux: external module not found

by Eliot Miranda

On Sat, Jan 7, 2012 at 5:16 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Sun, Jan 08, 2012 at 12:37:59AM +0000, Schwab,Wilhelm K wrote: > > Eliot, > > > > SOL?? Is that really the message we want to send to current and > *prospective* users? Canonical does something that makes sense from a > security perspective (one needs root privileges to alter the ldconfig > mapping, not to to use it). All the vm needs to do is request the > #moduleName as given, and users of Pharo "SOL" as a result? > > > > Please reconsider. > > > > Bill > > > > I think you are taking the response out of context. The actual statement > was "Then you're SOL :) You'd need to write new support for Ubuntu." > > You might take that as a gentle suggestion to expend a bit of effort > on it yourself. After all, it is open source, and Eliot is only one > person. He can't do everything for everybody without a little help > from the rest of us. > quite. i don't even have an ubuntu VM, let alone the time to work on it. Bill, instead of whining, pitch in, please. > > Dave > > > > > > > > > > ________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Eliot Miranda [ > eliot.miranda(a)gmail.com] > > Sent: Saturday, January 07, 2012 6:38 PM > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] Cog+linux: external module not found > > > > > > > > On Sat, Jan 7, 2012 at 8:49 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>> wrote: > > Nick, > > > > Partial success. After a false start with getting output from strace > (my fault), it showed me that the vm was looking a lot in the vm's > directory. A symlink by the same name, allowed it to see the library. > Clearly, this is not a fix, because one should not be forced to make links > to any/every library on the system. However, it *was* nice to see the > version string in an inspector :) > > > > Looking at the strace output (relevant parts below), it tries with > prepending lib, appending .so, .so.dylib. It looks in the vm's directory, > and in the root directory, not /usr/lib. > > > > It has been almost a year (based on a dated comment) since I last really > strained my synapses on the workings of ldconfig. On my systems, it would > tell one to look for the library as follows: > > > > ldconfig -p | grep Acces > > libAccesIO-USB.so (libc6) => /usr/lib/libAccesIO-USB.so > > > > #moduleName answers 'libAccesIO-USB.so', and Ian's vm finds it. My (and > I use the term LOOSELY) understanding is that Ubuntu no longer uses > LD_LIBRARY_PATH. dlopen() seems to prefer that one use the names as > reported by ldconfig. The best explanation I have found is that the change > was a security measure. > > > > Then you're SOL :) You'd need to write new support for Ubuntu. > > > > > > How does one get ldconfig to "know" where something lives? Putting a > .so file in /usr/lib (and perhaps other places too) and then running > ldconfig as sudo appears to build a cache. Then ldconfig -p (anyone can > run this) will show the map, and one can grep the result to find something > specifc, as above. > > > > Putting files in /usr/lib is a pain for things under active development. > A file can live anywhere if one puts a .conf file in /etc/ld.so.confd; the > .conf files should contain paths to directories to be searched for .so > files - or at least that's how it *appears* to work. Run ldconfig as sudo > to refresh the mapping, and verify with ldconfig - p. > > > > The fix might be as simply as having the cog vm try passing the > #moduleName to dlopen(). > > > > Nick, thanks for the nudge in a working direction. I will probably > symlink another file and see if a mix of hardware and software will get > closer to cooperating with me. > > > > Bill > > > > > -- best, Eliot

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Levente Uzonyi

On Mon, 9 Jan 2012, Mariano Martinez Peck wrote: > Hi Levente. Thanks for looking into the issue. I saw your code and there is > something I don't understand. > > pointsTo: anObject > "Answers true if the garbage collector would fail to collect anObject > because I hold a reference to it, or false otherwise" > > (self instVarsInclude: anObject) > ifTrue: [ > self class isWeak ifFalse: [ ^true ]. > 1 to: self class instSize do: [ :i | > (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. > ^false ] > ifFalse: [ ^self class == anObject and: [ self class isCompact not > ] ] > > > I don't understand the loop of > > 1 to: self class instSize do: [ :i | > (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. > > > In which scenario can (self instVarsInclude: anObject) answer true, > but the loop false? The scenario happens when the receiver has weak slots and the argument is referenced from one of those weak slots, but not from the other slots. > doesn't #instVarsInclude do exactly what you are doing there? Just partially. Since we have no information about which slots hold the reference to the argument, therefore this loop must be "repeated". > > Anyway, I have integrated your changes in Pharo, but still, I have the same > problem :( > If I understand correctly, the following shouldn't fail, but it does. Here > is the version of Squeak that fails. The assetion fails, because the indirection vector (the Array found by PointerFinder) holds a reference to the object after the first assignment to a. If you move the temporary inside the block or use an inlined loop (e.g. #to:do: with literal block argument), then the assertion won't fail. So this is just a normal (maybe surprising) reference to the object. Levente > > | a | > 10 timesRepeat: [ > a := Date new. > Smalltalk garbageCollect. > self assert: (PointerFinder pointersTo: a) isEmpty > ] > > Thanks a lot, > > > On Mon, Jan 9, 2012 at 2:40 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > > On Sun, 8 Jan 2012, Mariano Martinez Peck wrote: >> >> What I don't understand is why in Squeak it does work. >>>> >>>>> >>>>> >>>> Because #pointsTo: is not used in Squeak (yet). As usual I dug deeper >>>> than >>>> I should have, so I'll publish a few changes soon. >>>> >>>> >>>> Ok, you are right. Squeak #inboundPointersExcluding: is using >>> #instVarsInclude: rather than #pointsTo. And that solves the problem in >>> Pharo as well. But still, I would like to understand why we get those >>> method contexts with #pointsTo. >>> >> >> Because #pointsTo: is a normal message send, it even sends other methods, >> so it will create contexts. >> >> >> Thanks Levente for your help. If you find something let us know, I want to >>> learn :) >>> >> >> I pushed my changes to the Squeak Inbox, which fully works around this >> issue. The changes about weak references can simply be removed if you don't >> like them, the rest will just work without them. >> >> >> Levente >> >> >>> Thanks >>> >>> >>> >>>> Levente >>>> >>>> >>>> Thanks in advance Levente! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> it will create at least one new MethodContext which is not included in >>>>> >>>>>> that list. >>>>>> >>>>>> >>>>>> Levente >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Levente >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks again. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Levente >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Do you mean what I understand :)? that some tools compiled >>>>>>>>>> methods? >>>>>>>>>> :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Stef >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Mariano >>>>>>>>>>> http://marianopeck.wordpress.**********com < >>>>>>>>>>> http://marianopeck.wordpress. >>>>>>>>>>> **** >>>>>>>>>>> com <http://marianopeck.wordpress.******com<http://marianopeck.** >>>>>>>>>>> wordpress.com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> Mariano >>>>>>>>> http://marianopeck.wordpress.********com < >>>>>>>>> http://marianopeck.wordpress. >>>>>>>>> **** >>>>>>>>> com <http://marianopeck.wordpress.****com<http://marianopeck.** >>>>>>>>> wordpress.com <http://marianopeck.wordpress.com>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>> Mariano >>>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>>> **** >>>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Mariano >>>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>>> com <http://marianopeck.wordpress.com>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 9, 2012

Re: [Pharo-project] Bug in FileSystem

by Mariano Martinez Peck

So, here it is: http://code.google.com/p/pharo/issues/detail?id=5161 On Sun, Jan 8, 2012 at 2:39 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > >>> As for the API: >> >> 1) There's no next: into: (which returns the amount read). It's really >> the only way to do buffers without garbage allocations. >> > > Hi Henry. One of the extensions I needed to add to FSReadStream in order > to make it work with Fuel was exatly #next:into: > The method is: > > next: number into: aCollection > | count | > count := handle at: position read: aCollection startingAt: 1 count: > number. > > position := position + count. > ^ count < aCollection size > ifTrue: [aCollection first: count] > ifFalse: [aCollection] > > > I didn't understand what you meant by "It's really the only way to do > buffers without garbage allocations" > So...should I integrate this method #next:into: as it is together to the > fix to #read: > > > >> 2) FSHandle >>at: offset read: buffer startingAt: start count: count is a >> weirdly named selector for what it does imho... >> Doesn't #at: offset read: count into: buffer startingAt: start make more >> sense? >> >> Cheers, >> Henry >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2012

Re: [Pharo-project] Bug in #pointsTo: ?

by Mariano Martinez Peck

Hi Levente. Thanks for looking into the issue. I saw your code and there is something I don't understand. pointsTo: anObject "Answers true if the garbage collector would fail to collect anObject because I hold a reference to it, or false otherwise" (self instVarsInclude: anObject) ifTrue: [ self class isWeak ifFalse: [ ^true ]. 1 to: self class instSize do: [ :i | (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. ^false ] ifFalse: [ ^self class == anObject and: [ self class isCompact not ] ] I don't understand the loop of 1 to: self class instSize do: [ :i | (self instVarAt: i) == anObject ifTrue: [ ^true ] ]. In which scenario can (self instVarsInclude: anObject) answer true, but the loop false? doesn't #instVarsInclude do exactly what you are doing there? Anyway, I have integrated your changes in Pharo, but still, I have the same problem :( If I understand correctly, the following shouldn't fail, but it does. Here is the version of Squeak that fails. | a | 10 timesRepeat: [ a := Date new. Smalltalk garbageCollect. self assert: (PointerFinder pointersTo: a) isEmpty ] Thanks a lot, On Mon, Jan 9, 2012 at 2:40 PM, Levente Uzonyi <leves(a)elte.hu> wrote: On Sun, 8 Jan 2012, Mariano Martinez Peck wrote: > > What I don't understand is why in Squeak it does work. >>> >>>> >>>> >>> Because #pointsTo: is not used in Squeak (yet). As usual I dug deeper >>> than >>> I should have, so I'll publish a few changes soon. >>> >>> >>> Ok, you are right. Squeak #inboundPointersExcluding: is using >> #instVarsInclude: rather than #pointsTo. And that solves the problem in >> Pharo as well. But still, I would like to understand why we get those >> method contexts with #pointsTo. >> > > Because #pointsTo: is a normal message send, it even sends other methods, > so it will create contexts. > > > Thanks Levente for your help. If you find something let us know, I want to >> learn :) >> > > I pushed my changes to the Squeak Inbox, which fully works around this > issue. The changes about weak references can simply be removed if you don't > like them, the rest will just work without them. > > > Levente > > >> Thanks >> >> >> >>> Levente >>> >>> >>> Thanks in advance Levente! >>>> >>>> >>>> >>>> >>>> >>>> it will create at least one new MethodContext which is not included in >>>> >>>>> that list. >>>>> >>>>> >>>>> Levente >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Levente >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks again. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Levente >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Do you mean what I understand :)? that some tools compiled >>>>>>>>> methods? >>>>>>>>> :) >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Stef >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Mariano >>>>>>>>>> http://marianopeck.wordpress.**********com < >>>>>>>>>> http://marianopeck.wordpress. >>>>>>>>>> **** >>>>>>>>>> com <http://marianopeck.wordpress.******com<http://marianopeck.** >>>>>>>>>> wordpress.com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> >>>>>>>> Mariano >>>>>>>> http://marianopeck.wordpress.********com < >>>>>>>> http://marianopeck.wordpress. >>>>>>>> **** >>>>>>>> com <http://marianopeck.wordpress.****com<http://marianopeck.** >>>>>>>> wordpress.com <http://marianopeck.wordpress.com>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.******com <http://marianopeck.wordpress. >>>>>> **** >>>>>> com <http://marianopeck.wordpress.**com<http://marianopeck.wordpress.com> >>>>>> >> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.****com <http://marianopeck.wordpress.** >>>> com <http://marianopeck.wordpress.com>> >>>> >>>> >>>> >>> >> >> -- >> Mariano >> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com> >> >> > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2012

[Pharo-project] [update 1.4] #14280

by StÃ©phane Ducasse

14280 ----- - Issue 5149: add line in comment of VirtualMachine class>>parameterAt:. ThanksLuc Fabresse and Mariano Martinez-Peck. http://code.google.com/p/pharo/issues/detail?id=5149 - Issue 5132: CommentReference SourcedMethodReference MethodReference are now deprecated http://code.google.com/p/pharo/issues/detail?id=5132 - Issue 2560: Convenient methods from Grease for Strings. Thanks Sven van Caekenberghe. Part one. http://code.google.com/p/pharo/issues/detail?id=2560 Stef

Jan. 9, 2012

Re: [Pharo-project] How can I get account on Jenkins?

by Marcus Denker

On Jan 9, 2012, at 4:48 PM, StÃ©phane Ducasse wrote: > I will check. I'm not sure that without an inria account you can access it. Yes, an account for Jenkins is possible. An account on the unix machine not, but all that is needed is editing scripts and that we do via Git. Works fine for Mac VM, for example. > Now we can set up one. > in a month from now we will get a jenkins engineer working in our team. > > Stef > On Jan 9, 2012, at 3:42 AM, Dimitry Golubovsky wrote: > >> Hi, >> >> How can I get an account on Jenkins so I could set up build jobs for >> CogDroid? Such way, everybody interested could easily get access to >> the latest builds. Also, people who wish to experiment with derived >> versions (built on top of the core VM Java+native libraries) would be >> able to do it without messing with building the VM itself, just >> referencing the proper .jar and .so files. >> >> Thanks. >> >> -- >> Dimitry Golubovsky >> >> Anywhere on the Web >> > > -- Marcus Denker -- http://marcusdenker.de

Jan. 9, 2012

Re: [Pharo-project] How can I get account on Jenkins?

by StÃ©phane Ducasse

I will check. I'm not sure that without an inria account you can access it. Now we can set up one. in a month from now we will get a jenkins engineer working in our team. Stef On Jan 9, 2012, at 3:42 AM, Dimitry Golubovsky wrote: > Hi, > > How can I get an account on Jenkins so I could set up build jobs for > CogDroid? Such way, everybody interested could easily get access to > the latest builds. Also, people who wish to experiment with derived > versions (built on top of the core VM Java+native libraries) would be > able to do it without messing with building the VM itself, just > referencing the proper .jar and .so files. > > Thanks. > > -- > Dimitry Golubovsky > > Anywhere on the Web >

Jan. 9, 2012