- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problems with updates 1.0 & 1.1 on XP ...

by StÃ©phane Ducasse

Can you tell us more your setup? We are several on mac and got no problem. Now for Windows we need more information. Stef On Dec 10, 2009, at 12:56 AM, Guido Stepken wrote: > Hi folks! > > I installed recent Pharo 1.0 and downloaded also the 1.1 alpha Image. > > Updating both fails finally. 1.1 stops updating at a certain point, 1.0 > updates, but classbrowser finally doesn't work. > > Any ideas? > > tnx, Guido > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 10, 2009

Re: [Pharo-project] ClassTree new openOn: Collection :)

by Tudor Girba

Dec. 10, 2009

[Pharo-project] roelTyper doesn't always return assignements

by Cyrille Delaunay

Hi, I'm trying to use RoelTyper in Pharo. A question I ask myself is: 'Is it normal that roelTyper doesn't always return some assignements' ? For example, when I evaluate: TypeCollector typeInstvar: #array ofClass: OrderedCollection . the assignements returned is an empty collection. I would expect that even roelTyper doesn't retrieve the exact type, it would always return a collection of 'candidate' types. Am I using it in a wrong way?

Dec. 10, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Adrian Lienhard

The objects in the segment's byte array are "instantiated" by the primitive #loadSegmentFrom:outPointers:. In fact they are not instantiated, but the byte array is just twisted a bit to represent real objects on the heap (internal references and indexes into outPointers are remapped). Adrian On Dec 10, 2009, at 01:59 , Sheridan Mahoney wrote: > > > > Adrian Lienhard wrote: >> >> >> On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote: >> >>> On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >> >>> When you are creating your root of objects and you put symbols >>> inside, they >>> are not put in ourPointers but in ByteArray. >>> This is due to the fact that the only object who is pointing to that >>> symbol >>> is inside the segment ? >> >> To be precise, the symbols are also pointed to by the symbol table, >> but only by weak references. Since image segments use the GC mark >> logic, these pointers are not considered. >> >> > > Martin and I had been working towards the idea that ImageSegments > should > never create non-Canonical symbols, and the user should not have to > use > manual techniques to preserve symbols they are interested in keeping > alive. > > I ended up getting stuck however, in trying to discover what process > ImageSegment > goes through while it is installing objects - ImageSegment #install > has a > call to an > unimplemented method #readFromFileWithSymbols which it seems it > should be > using, but isn't....(wha' the?) > > > install > "This operation retrieves the segment if necessary from file storage, > installs it in memory, and replaces (using become:) all the root > stubs with > the reconstructed roots of the segment." > > | newRoots | > state = #onFile ifTrue: [self readFromFile]. > state = #onFileWithSymbols ifTrue: [self readFromFileWithSymbols. > endMarker := segment nextObject. "for enumeration of objects" > endMarker == 0 ifTrue: [endMarker := 'End' clone]]. > (state = #active) | (state = #imported) ifFalse: [self > errorWrongState]. > newRoots := self loadSegmentFrom: segment outPointers: outPointers. > state = #imported > ifTrue: ["just came in from exported file" > arrayOfRoots := newRoots] > ifFalse: [ > arrayOfRoots elementsForwardIdentityTo: newRoots]. > state := #inactive. > Beeper beepPrimitive > > > I think the next step in this trajectory is to trace is how the > state is > getting > set - right now it is kind of a mystery... > > Does this seem reasonable? > > Thanks, > > Sheri > > > -- > View this message in context: http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4143090.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 10, 2009

Re: [Pharo-project] Issue 1554

by Damien Cassou

2009/12/8 Adrian Lienhard <adi(a)netstyle.ch>: > Thanks for your contribution. > > Your change is in the package Ocompletion, which is outside Pharo- > core. This package is maintained by Romain. I added Romain to CC so he > can merge your fix into the main branch of Ocompletion. Done. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Dec. 10, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Adrian Lienhard

Hi Mariano, I don't understand your question(s)... If you have some code, that would probably help. Cheers, Adrian On Dec 9, 2009, at 21:06 , Mariano Martinez Peck wrote: > On Wed, Dec 9, 2009 at 9:40 AM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> I don't have the VMMaker code at hand right now (or rather, don't >> have >> time to look at it ;)), but I guess that after that piece of code you >> pasted below there is a loop from the first field (BaseHeader+4) to >> the last non-weak field (lastFieldOffset) in which the non-weak >> fields >> are traced. Note, that if an object both fixed and indexable weak >> fields the latter are always located after the former. You can see >> the >> memory layout and object formats on the pages 9 and 10 of the slides >> [1] (from a lecture about VMs I gave recently). >> >> > Thanks for the explanation Adrian and the link Adrian...now, being a > bit > off-topic, I have the following situation about ImageSegment. I > tried to > reproduce it in a unit test, but I couldn't yet :( > > Suppose I create a segment with a tree of objects. Suppose inside of > that > tree I have an object that refers to an external object called XXX, > thus it > is put in the outPointers. > Then I extract the segment, I write it to disk, and I put a nil to the > segment variable. > After that, for some reason, my object XXX is garbage collected from > my > image. > Then I want to load again my segment (reading the file and > installling it). > What happens ? it fails? If true, suppose I have already "installed" > some > other objects, what happen with those objects? is this atomic ? > > Thanks a lot for anyone that can give me a hint. > > Mariano > > > >> Cheers, >> Adrian >> >> [1] http://www.adrian-lienhard.ch/presentations >> >> On Dec 8, 2009, at 22:57 , Mariano Martinez Peck wrote: >> >>> On Tue, Dec 8, 2009 at 10:54 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Dec 8, 2009 at 5:07 PM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>> >>>>> >>>>> On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote: >>>>> >>>>>> On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard >>>>>> <adi(a)netstyle.ch> >>>>>> wrote: >>>>> >>>>>> When you are creating your root of objects and you put symbols >>>>>> inside, they >>>>>> are not put in ourPointers but in ByteArray. >>>>>> This is due to the fact that the only object who is pointing to >>>>>> that >>>>>> symbol >>>>>> is inside the segment ? >>>>> >>>>> To be precise, the symbols are also pointed to by the symbol >>>>> table, >>>>> but only by weak references. Since image segments use the GC mark >>>>> logic, these pointers are not considered. >>>>> >>>> >>>> Ahhh ok. Now I see Symbol class >> rehash where it sets to >>>> SymbolTable >>>> := WeakSet >>>> >>>> Now...my finally question is, where in the code you can see the GC >>>> only >>>> mark "normal" objects and that week objects are not being taken >>>> into >>>> account. Do you know ? I tried to search it but I didn't find it. >>>> >>>> >>> Sorry, I forgot to said I found this in ObjectMemory >> >>> markAndTrace: >>> >>> (self isWeakNonInt: oop) ifTrue: [ >>> "Set lastFieldOffset before the weak fields in the receiver" >>> lastFieldOffset := (self nonWeakFieldsOf: oop) << >>> ShiftForWord. >>> "And remember as weak root" >>> weakRootCount := weakRootCount + 1. >>> weakRoots at: weakRootCount put: oop. >>> ] ifFalse: [ >>> "Do it the usual way" >>> lastFieldOffset := self lastPointerOf: oop. >>> ]. >>> >>> >>> But I don't know if this make sense or not. >>> >>> Thanks!! >>> >>> Mariano >>> >>> >>>>>> What you do with this piece of code: >>>>>> >>>>>> symbolHolder := Symbol allSymbols. >>>>>> >>>>>> is to hold those symbols there. So, when ImageSegment uses the GC >>>>>> techniques >>>>>> to detect which objects are ONLY pointed from inside of the >>>>>> segment, >>>>>> the >>>>>> symbols is not found (because it is accessible trough that test) >>>>>> and >>>>>> thus, >>>>>> it goes to outPointers instead of ByteArray. >>>>>> >>>>>> And of course, if it is in outPointers instead of ByteArray when >>>>>> the >>>>>> segment >>>>>> is loaded again, yo don't create a symbol again but use the same >>>>>> object (the >>>>>> one of the oop). >>>>>> >>>>>> I am correct? or I understood anything ? >>>>> >>>>> yes. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 10, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Mariano Martinez Peck

On Thu, Dec 10, 2009 at 3:32 AM, Martin McClure <martin(a)hand2mouse.com>wrote: > Sheridan Mahoney wrote: > > > Martin and I had been working towards the idea that ImageSegments should > > never create non-Canonical symbols, and the user should not have to use > > manual techniques to preserve symbols they are interested in keeping > alive. > > > > I ended up getting stuck however, in trying to discover what process > > ImageSegment > > goes through while it is installing objects - ImageSegment #install has > a > > call to an > > unimplemented method #readFromFileWithSymbols which it seems it should > be > > using, but isn't....(wha' the?) > > > > > > install > > "This operation retrieves the segment if necessary from file > storage, > > installs it in memory, and replaces (using become:) all the root stubs > with > > the reconstructed roots of the segment." > > > > | newRoots | > > state = #onFile ifTrue: [self readFromFile]. > > state = #onFileWithSymbols ifTrue: [self readFromFileWithSymbols. > > My guess (and only a guess) is that #onFileWithSymbols never becomes a > state in the test case that's failing. > > Yes! > And my opinion is that it's suspicious to require something different > for a image segment that contains symbols as opposed to one that > doesn't; the ideal would be to have image segments just transparently > handle Symbols correctly. Users just shouldn't have to deal with details > at that level; the correct semantics are extremely clear. > 142% agree. So...there are a couple of things I think ImageSegment should do instead of the user: 1) If you put in the segment a class, ImageSegment automatically puts also the metcaclass. 2) Deal transparently if you put symbols in the segment. 3) Evaluate "Smalltalk garbageCollect" after the message "extract". This is most of the cases something you want to do. I addition, look the senders of extract and you will see that in most of the cases, after doing the extract, it evaluates a garbageCollect. Cheers, Mariano > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 10, 2009

Re: [Pharo-project] How to report a bug ? [WAS] lukas-renggli.ch down, mirrors exists ?

by Adrian Lienhard

Thanks for pointing this out. I fixed the template. It should be either "Pharo" or "Pharo-core". Adrian On Dec 9, 2009, at 19:45 , Michael Roberts wrote: > Hi, I like the template! > > However, we are mixing our brand up a bit. I thought we agreed we > would not call the pharo image a dev image? or did I miss something? > So we are in this state where some things (e.g the installers, the > pharo images) have dev in their name/filename, and sometimes we just > call it Pharo in our documentation and conversation. We should try > and be consistent, or rethink the branding. It's caused by us having > one artifact without a suffix, whereas the rest do. (pharo, > pharo-core, pharo-web). > > thanks, > Mike > > On Thu, Dec 3, 2009 at 12:55 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> Thanks, I updated the template. >> >> Adrian >> >> On Dec 3, 2009, at 11:26 , laurent laffont wrote: >> >>> A first template: >>> >>> >>> If you fill an issue for the first time, please read "How to report >>> bugs" >>> at http://www.pharo-project.org/community/issue-tracking >>> >>> Pharo image: <core, dev or web> >>> Pharo core version: <copy from World/System/About> >>> Virtual machine used: <ex: pharo-vm-0.15.2f-linux> >>> Class browser used if applicable: <ex: O2PackageBrowserAdaptor. If >>> you don't >>> know, print "SystemBrowser default"> >>> >>> Steps to reproduce: >>> 1. >>> 2. >>> 3. >>> >>> >>> Paste or attach stack trace if applicable (look at the file >>> PharoDebug.log >>> located in the same directory as your image): >>> >>> Thank you ! >>> >>> Laurent >>> >>> 2009/12/3 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>>> Adrian: Thanks for your changes! It looks much better :) >>>> >>>> Laufert: yes, that's a cool idea. I wasn't aware neither. >>>> >>>> Could someone write a template? Then we just add the link to the >>>> new page. >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> >>>> On Thu, Dec 3, 2009 at 10:44 AM, Adrian Lienhard <adi(a)netstyle.ch> >>>> wrote: >>>> >>>>> ah, I didn't know that is possible. Good idea! >>>>> >>>>> Adrian >>>>> >>>>> On Dec 3, 2009, at 10:34 , laurent laffont wrote: >>>>> >>>>>> May be you should fill the issue templates on google code issue >>>>>> tracker. >>>>>> Like this: http://code.google.com/p/chromium/issues/entry >>>>>> >>>>>> Laurent >>>>>> >>>>>> >>>>>> On Thu, Dec 3, 2009 at 10:18 AM, Adrian Lienhard >>>>>> <adi(a)netstyle.ch> >>>>>> wrote: >>>>>> >>>>>>> Thanks Mariano. I have condensed your text a bit and put it >>>>>>> online at >>>>>>> http://www.pharo-project.org/community/issue-tracking >>>>>>> >>>>>>> Cheers, >>>>>>> Adrian >>>>>>> >>>>>>> BTW, I also added the milestones for version 1.1 on the home >>>>>>> page. >>>>>>> >>>>>>> On Dec 2, 2009, at 18:43 , Mariano Martinez Peck wrote: >>>>>>> >>>>>>>> I think it is really a good idea to create a page in the Pharo >>>>>>>> website about >>>>>>>> how to report a bug. I think that only the link to the google >>>>>>>> page >>>>>>>> is not >>>>>>>> enough. Maybe it is a good idea to explain it a bit more, and >>>>>>>> in >>>>>>>> addition, >>>>>>>> give some tips. I would write something like the text above in >>>>>>>> that >>>>>>>> page. I >>>>>>>> would replace everywhere where it is a link to >>>>>>>> http://code.google.com/p/pharo/issues/list to this new page. >>>>>>>> I saw >>>>>>>> there >>>>>>>> are these >>>>>>>> >>>>>>>> http://www.pharo-project.org/home (on the right) >>>>>>>> http://www.pharo-project.org/documentation/faq (in the >>>>>>>> question >>>>>>>> "Where do I >>>>>>>> report Pharo bugs?") >>>>>>>> >>>>>>>> My English is not the best at all, so any feedback is more than >>>>>>>> welcome. In >>>>>>>> addition, maybe you don't agree with me. >>>>>>>> >>>>>>>> My main purpose is to help newcomers to submit issues. >>>>>>>> >>>>>>>> So....here it is >>>>>>>> >>>>>>>> >>>>>>>> " >>>>>>>> An issue, also known as ticket, represents many things. It can >>>>>>>> be a >>>>>>>> bug, a >>>>>>>> enchantment, packages, projects or commits to check, etc. >>>>>>>> For the Pharo project, we use the Google Code issue tracker >>>>>>>> which is >>>>>>>> in >>>>>>>> http://code.google.com/p/pharo/issues/list. >>>>>>>> >>>>>>>> - Before submitting you may take into account the following >>>>>>>> tips: >>>>>>>> >>>>>>>> 1) Search in the existent issue list if there is something >>>>>>>> similar. >>>>>>>> In the >>>>>>>> issue tracker you will find a "search" button to do that. Be >>>>>>>> aware >>>>>>>> that >>>>>>>> there is a list of options and the default one is "Open >>>>>>>> ticket". It >>>>>>>> is very >>>>>>>> common you need to search in "All issues". >>>>>>>> >>>>>>>> 2) If the ticket is a bug, and there is a problem with certain >>>>>>>> method, >>>>>>>> search for that method or even for that class. It is very >>>>>>>> common to >>>>>>>> have >>>>>>>> "MessageNotUnderstood". So, in this case you can search for >>>>>>>> that >>>>>>>> method. For >>>>>>>> example, if you evaluate: >>>>>>>> >>>>>>>> TestCase nonExistentMethod: something other: another >>>>>>>> >>>>>>>> You will get "MessageNotUnderstood: TestCase >>>>>>>> class>>nonExistentMethod:other:" >>>>>>>> >>>>>>>> So, here you can search for "nonExistentMethod:other:" for >>>>>>>> exampe. >>>>>>>> >>>>>>>> 3) Do the same of 1) and 2) but on the mailing list. If you are >>>>>>>> new >>>>>>>> or even >>>>>>>> if you are not subscribed, you can see and search in the >>>>>>>> mailing >>>>>>>> list here: >>>>>>>> http://n2.nabble.com/Pharo-Smalltalk-f2305563.html >>>>>>>> >>>>>>>> Sometimes some tickets are reported only in mailing list >>>>>>>> (that's too >>>>>>>> bad!!!). And maybe, that happened before you get subscribed in >>>>>>>> the >>>>>>>> mailing >>>>>>>> list. This way you are sure you are searching also in the >>>>>>>> mailing >>>>>>>> list. >>>>>>>> >>>>>>>> >>>>>>>> - When you are submitting an issue there are also some tips you >>>>>>>> should take >>>>>>>> into account: >>>>>>>> >>>>>>>> 1) If the issue is related to ClassBrowser, refactor or >>>>>>>> similar, >>>>>>>> please tell >>>>>>>> us which browser are you using. If you don't know it, just >>>>>>>> evaluate >>>>>>>> and see >>>>>>>> the results of "SystemBrowser default". >>>>>>>> >>>>>>>> 2) ALWAYS say which version of VM, image (not only if it is a >>>>>>>> core >>>>>>>> or pharo >>>>>>>> image but also exactly the version) and OS are you using. >>>>>>>> >>>>>>>> 3) If the bug is reproducible, please explain how to do it step >>>>>>>> by >>>>>>>> step. If >>>>>>>> we have to use a particular VM, OS, or image, say it. >>>>>>>> >>>>>>>> 4) If the bug brings a debugger popup, it would be very >>>>>>>> useful if >>>>>>>> you could >>>>>>>> put in the issue entry the full stacktrace. To get this >>>>>>>> stacktrace, >>>>>>>> there >>>>>>>> are 2 ways: >>>>>>>> >>>>>>>> 4.a) Search for the generated PharoDebug.log which is in the >>>>>>>> same >>>>>>>> directory >>>>>>>> where if image is and attached in the issue. In that file there >>>>>>>> is >>>>>>>> not only >>>>>>>> the full stacktrace but also some information about the version >>>>>>>> of >>>>>>>> the VM, >>>>>>>> OS and image you were using at that moment, etc. >>>>>>>> >>>>>>>> 4.b) In the debugger, open the contextual menu and there is an >>>>>>>> item >>>>>>>> 'mail >>>>>>>> out bug report' to directly send the stack trace with VM >>>>>>>> version etc >>>>>>>> to the >>>>>>>> pharo list (or whoever you want to, but by default it's the >>>>>>>> Pharo >>>>>>>> ml). Of >>>>>>>> course you can edit the message to describe your problem for >>>>>>>> example. >>>>>>>> >>>>>>>> 5) If you are not a newcomer and you know a bit you can put >>>>>>>> labels >>>>>>>> to the >>>>>>>> issue. For example if it should be Milestone 1.0 or Type- >>>>>>>> Closure, or >>>>>>>> TypeOB, >>>>>>>> etc. >>>>>>>> >>>>>>>> 6) If you are not a newcomer and you know a bit you can copy >>>>>>>> people >>>>>>>> with the >>>>>>>> "Cc:" option. This is very useful when you know that the >>>>>>>> issue is >>>>>>>> in a >>>>>>>> certain package for example and you know who is responsible or >>>>>>>> maintainer of >>>>>>>> it. >>>>>>>> >>>>>>>> 7) After submitting the issue, you must send and email to the >>>>>>>> mailing list >>>>>>>> with the link. What you can do also is to copy and paste the >>>>>>>> details >>>>>>>> of the >>>>>>>> issue in the body of the email. With this, all the people know >>>>>>>> about >>>>>>>> it. >>>>>>>> >>>>>>>> 8) If the ticket is a MNU it would be very useful to put that >>>>>>>> message (in >>>>>>>> our example "MessageNotUnderstood: TestCase >>>>>>>> class>>nonExistentMethod:other:") in the description of the >>>>>>>> ticket >>>>>>>> or even >>>>>>>> in the title of the issue and the subject of the email. With >>>>>>>> this we >>>>>>>> can >>>>>>>> take advantage of the Google search engine. >>>>>>>> >>>>>>>> 9) If you have a fix remember you must sign the MIT license >>>>>>>> first. >>>>>>>> For more >>>>>>>> information read http://www.pharo-project.org/license >>>>>>>> >>>>>>>> " >>>>>>>> >>>>>>>> On 2 dÃ©c. 2009, at 08:05, Mariano Martinez Peck wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2009/12/2 laurent laffont <laurent.laffont(a)gmail.com> >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I want to check if there's updates to Slime package as I faces >>>>>>>>> several bugs >>>>>>>>> but sources.lukas-renggli.ch seems to be down. Is there a >>>>>>>>> mirror ? >>>>>>>>> >>>>>>>>> >>>>>>>>> About the bugs (Slime-lr.24,current pharo rc1 web image), >>>>>>>>> when I >>>>>>>>> select >>>>>>>>> refactor > code critics: >>>>>>>>> >>>>>>>>> - it seems that ParserTreeSearcher has been renamed to >>>>>>>>> RBParserTreeSearcher. Thus there's several errors like >>>>>>>>> WAChangesStateWhileRenderingRule>>initialize >>>>>>>>> (ParseTreeSearcher is >>>>>>>>> Undeclared) >>>>>>>>> >>>>>>>>> - this done, I have the error: >>>>>>>>> AnObsoleteParseTreeSearcher(Object)>>doesNotUnderstand: >>>>>>>>> #executeTree:initialAnswer: (from >>>>>>>>> RBAssignmentIfTrueRule>>checkMethod:) >>>>>>>>> >>>>>>>>> >>>>>>>>> How do I save a stack trace to a text file (or clipboard) from >>>>>>>>> the >>>>>>>>> debugger >>>>>>>>> ? >>>>>>>>> >>>>>>>> >>>>>>>> Look for the file called PharoDebug.log which is in the >>>>>>>> directory >>>>>>>> where the >>>>>>>> image is. It will have not only the stacktrace but also much >>>>>>>> more >>>>>>>> information, as VM version, OS, etc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> or.... >>>>>>>> >>>>>>>> In the debugger, open the contextual menu and there is an item >>>>>>>> 'mail >>>>>>>> out bug >>>>>>>> report' to directly send the stack trace with VM version etc to >>>>>>>> the >>>>>>>> pharo >>>>>>>> list (or whoever you want to, but by default it's the Pharo >>>>>>>> ml). Of >>>>>>>> course >>>>>>>> you can edit the message to make it shorter (we dont need the >>>>>>>> full >>>>>>>> stack in >>>>>>>> general) and describe your problem etc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Mariano >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Laurent Laffont >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>>> project >>>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 10, 2009

[Pharo-project] ImageSegment [WAS] getting rid of Symbol >> new: ?

by Mariano Martinez Peck

On Thu, Dec 10, 2009 at 1:59 AM, Sheridan Mahoney < sheridan(a)sheridan-mahoney.com> wrote: > > > > Adrian Lienhard wrote: > > > > > > On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote: > > > >> On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi(a)netstyle.ch> > >> wrote: > > > >> When you are creating your root of objects and you put symbols > >> inside, they > >> are not put in ourPointers but in ByteArray. > >> This is due to the fact that the only object who is pointing to that > >> symbol > >> is inside the segment ? > > > > To be precise, the symbols are also pointed to by the symbol table, > > but only by weak references. Since image segments use the GC mark > > logic, these pointers are not considered. > > > > > > Martin and I had been working towards the idea that ImageSegments should > never create non-Canonical symbols, what does non-Canonical mean ? > and the user should not have to use > manual techniques to preserve symbols they are interested in keeping alive. > > +9999 agree. > I ended up getting stuck however, in trying to discover what process > ImageSegment > goes through while it is installing objects - ImageSegment #install has a > call to an > unimplemented method #readFromFileWithSymbols which it seems it should > be > using, but isn't....(wha' the?) > > yes. We should try to look in the old squeak images (like 3.6). I tried to make it work, but my machine seems to be too new :( Does someone has an old squeak running and has this method implemented? > > install > "This operation retrieves the segment if necessary from file > storage, > installs it in memory, and replaces (using become:) all the root stubs with > the reconstructed roots of the segment." > > | newRoots | > state = #onFile ifTrue: [self readFromFile]. > state = #onFileWithSymbols ifTrue: [self readFromFileWithSymbols. > endMarker := segment nextObject. "for enumeration of > objects" > endMarker == 0 ifTrue: [endMarker := 'End' clone]]. > (state = #active) | (state = #imported) ifFalse: [self > errorWrongState]. > newRoots := self loadSegmentFrom: segment outPointers: outPointers. > state = #imported > ifTrue: ["just came in from exported file" > arrayOfRoots := newRoots] > ifFalse: [ > arrayOfRoots elementsForwardIdentityTo: newRoots]. > state := #inactive. > Beeper beepPrimitive > > > I think the next step in this trajectory is to trace is how the state is > getting > set - right now it is kind of a mystery... > > Easy, see the senders of onFileWithSymbols.There are 4, but the more important is writeToFileWithSymbols which is also called by writeToFileWithSymbols: So, if you don't use any of those messages, the state never would be onFileWithSymbols. Try to write a test using that message and you will probably get the DNU. In addition, as you said, the user shouldn't even be care about this method. He should just send the message "writeToDisk". I have the same impression with the classes. When you store in a segment a class, you must also put the metaclass. And I think this can be automatically be done by ImageSegment instead of the user. > Does this seem reasonable? > > Thanks, > > Sheri > > > -- > View this message in context: > http://n2.nabble.com/Re-getting-rid-of-Symbol-new-tp4109230p4143090.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 10, 2009

Re: [Pharo-project] getting rid of Symbol >> new: ?

by Martin McClure

Sheridan Mahoney wrote: > Martin and I had been working towards the idea that ImageSegments should > never create non-Canonical symbols, and the user should not have to use > manual techniques to preserve symbols they are interested in keeping alive. > > I ended up getting stuck however, in trying to discover what process > ImageSegment > goes through while it is installing objects - ImageSegment #install has a > call to an > unimplemented method #readFromFileWithSymbols which it seems it should be > using, but isn't....(wha' the?) > > > install > "This operation retrieves the segment if necessary from file storage, > installs it in memory, and replaces (using become:) all the root stubs with > the reconstructed roots of the segment." > > | newRoots | > state = #onFile ifTrue: [self readFromFile]. > state = #onFileWithSymbols ifTrue: [self readFromFileWithSymbols. My guess (and only a guess) is that #onFileWithSymbols never becomes a state in the test case that's failing. And my opinion is that it's suspicious to require something different for a image segment that contains symbols as opposed to one that doesn't; the ideal would be to have image segments just transparently handle Symbols correctly. Users just shouldn't have to deal with details at that level; the correct semantics are extremely clear. Regards, -Martin

Dec. 10, 2009