... how does Parrot enumerate the thread stack? On Thu, Apr 3, 2008 at 9:33 AM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > On Thu, Apr 3, 2008 at 1:03 PM, Senaka Fernando <[EMAIL PROTECTED]> wrote: > > Hi Xiao-Feng, Alexei, > > > > Well that shouldn't take that long I guess. I'm a bit familiar now on the > > Harmony end, and I have been hacking parrot's interface too. Have patched > > one bug there and working on some more. They are keen in improving their > GC > > interface. I'm getting good cooperation on that end. > > > > Will work on the doc, from now, util I have something solid. I will use > the > > wiki for this. > > > > hmm, I am not sure if you are already familiar with the Harmony end, > since you haven't asked tough questions yet. ;) > > For example, one core issue: what are the object representations of > Hamrony and Parrot? i.e., how an object is laid out in heap? > > Some others like, can Parrot move objects in heap? Does Parrot require > to pin some objects in fixed positions during their lifetime? > > Thanks, > xiaofeng > > > > > Regards, > > Senaka > > > > On Thu, Apr 3, 2008 at 6:39 AM, Alexei Fedotov <[EMAIL PROTECTED]> > > > > > > wrote: > > > > > Senaka, that's a great idea. > > > > > > I fully support Xiao Feng's suggestion on documenting GC interface > > > differences as the best step for this moment. It sets a good > > > background. It has a quick and useful deliverable. Somehow I missed it > > > when thought about planning. > > > > > > On Thu, Apr 3, 2008 at 4:58 AM, Xiao-Feng Li <[EMAIL PROTECTED]> > > > wrote: > > > > On Thu, Apr 3, 2008 at 4:26 AM, Alexei Fedotov <[EMAIL PROTECTED]> > > > wrote: > > > > > Senaka, > > > > > An open source is a place where you are free to do what do you > want. > > > > > Let me just share my advise on being focused and don't let this > > > advise > > > > > to ruin your fun. > > > > > > > > > > At this point I would recommend you to use a control version > system > > > > > instead of defines. In other words, rewrite or remove portions of > > > > > files freely and commit checkpoints where you are able to build > the > > > > > whole code base into your local control version system. When you > get > > > > > things working it would be easy to arrange all defines. > > > > > > > > > > Imagine: you may spend a day putting defines to make a file > compile, > > > > > and throw the whole file tomorrow since it will be rewritten for > > > > > Parrot compatibility. > > > > > > > > Reasonable. It could be heavy-lifting at the beginning to consider > too > > > > much of VM-independent issues. On the other hand, it's interesting to > > > > read the findings and discussions here about the issues. It > enlightens > > > > me to think more. > > > > > > > > Btw, I don't want to discourage, but can be slow down the code > hacking > > > > a little bit. :-) At the moment, I think the most important is to > > > > understand the overall interface and infrastructure differences > > > > between Harmony and Parrot. To document them could be a better > > > > starting point, and the doc would be a strong fact to help the > project > > > > be approved by Google... > > > > > > > > Thanks, > > > > xiaofeng > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > On Wed, Apr 2, 2008 at 9:46 PM, Senaka Fernando <[EMAIL > PROTECTED]> > > > wrote: > > > > > > Hi all, > > > > > > > > > > > > At present, the gc_gen is built as a part of the VM, but if we > > > are to make > > > > > > it possible for it to be built separately, a define is needed > so > > > that the > > > > > > un-wanted stuff can be stripped off. How about GC_INDEPENDENT, > as > > > the name > > > > > > of the define? > > > > > > > > > > > > Regards, > > > > > > Senaka > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > With best regards, > > > > > Alexei > > > > > > > > > > > > > > > > > > > > > -- > > > > http://xiao-feng.blogspot.com > > > > > > > > > > > > > > > > -- > > > With best regards, > > > Alexei > > > > > > > > > -- > > > http://xiao-feng.blogspot.com >
-- With best regards, Alexei
