Thanks, Fred!
I can confirm that your change fixes the crash for me. I'll see about providing
a test case that demonstrates my issue #1 soon.
Cheers,
Doug
On Apr 4, 2012, at 3:38 PM, Fred Kiefer wrote:
> Hi Doug,
>
> thank you for providing this test code. I could reproduce the problem
> and
Hi Doug,
thank you for providing this test code. I could reproduce the problem
and have committed a simplified version of your test code to SVN. Plus a
solution to the problem.
It turned out to be caused by the private document I use to hold
detached nodes. This together with the code that allows
Hello Fred,
Thanks for all of your work on the XML classes, and for your summary of the
areas that still need attention. My original issue #1 (at the beginning of this
thread) is still outstanding as well. My issues #2 and #3 have been resolved --
thanks!
As it happens, I managed to get back t
Doug, you never replied to this mail. This hopefully means all your
issues were resolved.
In the meantime I added a few more features to our libxml2 wrapper, but
wont have much time to work on this area in the future. I also found
another nice implementation of some of these classes: KissXML
Hi Doug,
thank you for taking the time to test the new XML implementation in detail.
On 23.03.2012 01:24, Doug Simons wrote:
Hi Fred,
I finally found some time to try the XML code with your recent
changes. First, I appreciate all of the work you've done to finish up
the parts of this code that
Hi Fred,
I finally found some time to try the XML code with your recent changes. First,
I appreciate all of the work you've done to finish up the parts of this code
that we weren't able to complete in the initial implementation. Also, I can
confirm that the change you made to implement prettyPr
If there is anything I can do to help you with that remaining issue just
ask. This whole libxml2 stuff is a lot more complicated than I expected
and only real code that tests things can help here.
Most likely I will stop working on this area within the next few days
and things will have to wai
Hi Fred!
This is awesome. The app works now! :)
There are a few issues remaining, and only one *might* be related to NSXML.
I'll investigate each and open new discussions.
Thanks for all the wonderful, wonderful work!
On Sun, Mar 18, 2012 at 13:23, Fred Kiefer wrote:
> On 17.03.2012 21:24, Fr
On 17.03.2012 21:24, Fred Kiefer wrote:
On 17.03.2012 17:39, Ivan Vučica wrote:
Now that the code in SlaveOPML for creating new outlines from scratch
works
(including saving), I've spent some time trying to figure out why the
program crashes at opening the app. I'm stuck near the beginning; all
On 17.03.2012 17:39, Ivan Vučica wrote:
Now that the code in SlaveOPML for creating new outlines from scratch works
(including saving), I've spent some time trying to figure out why the
program crashes at opening the app. I'm stuck near the beginning; all I
could figure out is the stack trace.
C
Hi Fred, all,
On Thu, Mar 8, 2012 at 17:40, Ivan Vučica wrote:
> On Wed, Mar 7, 2012 at 23:33, Fred Kiefer wrote:
>
>>
>> Ah, now I see where the misunderstanding comes from. Here is your code
>> for replacementClassForClass:
>>
>>
>> +(Class)**replacementClassForClass:(**Class)cls
>> {
>>i
On 29.02.2012 23:28, Doug Simons wrote:
Since we've submitted the new implementation of the NSXML... classes
based on libxml2 and people are beginning to use them, I thought I
would mention some remaining unresolved issues in the hope that other
people might have more experience with the libxml2
On Wed, Mar 7, 2012 at 23:33, Fred Kiefer wrote:
>
> Ah, now I see where the misunderstanding comes from. Here is your code for
> replacementClassForClass:
>
>
> +(Class)**replacementClassForClass:(**Class)cls
> {
>if(cls == [NSXMLElement class])
>{
>return [OPMLOutlineXMLElement
On 07.03.2012 21:58, Ivan Vučica wrote:
On Sunday, March 4, 2012, Fred Kiefer wrote:
On 04.03.2012 22:32, Ivan Vučica wrote:
Subclassing NSXMLElement and overriding +[NSXMLDocument
replacementClassForClass:] (still nonfunctional in GNUstep)
Sorry, I am mostly interested in this small part
On Sunday, March 4, 2012, Fred Kiefer wrote:
> On 04.03.2012 22:32, Ivan Vučica wrote:
>
>> Subclassing NSXMLElement and overriding +[NSXMLDocument
>> replacementClassForClass:] (still nonfunctional in GNUstep)
>>
>
> Sorry, I am mostly interested in this small part of your mail. Why do you
> thin
On 6 Mar 2012, at 09:21, Wolfgang Lux wrote:
>> Under the current scheme, as long as the application holds a retain on any
>> Obj-C object anywhere in the tree, the entire underlying tree structure and
>> any other Obj-C objects that have been instantiated as part of it are kept
>> in memory. W
Doug Simons wrote:
> Now, at some point in time every object in the application with a direct
> reference to Ancestor is released, causing Ancestor to be fully released and
> (under the scheme you're proposing) deallocated. Suddenly and without
> warning, through no action of its own, Son is de
On 04.03.2012 22:32, Ivan Vučica wrote:
Subclassing NSXMLElement and overriding +[NSXMLDocument
replacementClassForClass:] (still nonfunctional in GNUstep)
Sorry, I am mostly interested in this small part of your mail. Why do
you think that this method is still non-functional? Do you have an
>From what I understand, you want to access siblings by asking the parent about
>the sibling, even though the parent is destroyed?
That's as if a member of NSArray counted on the NSArray being kept around
instead of keeping interesting objects around. If the parent is removed, child
shouldn't c
Thank you Doug for your comprehensiv reply. I now understand the reasoning
behind the old code a lot better. Being able to manipulate multiple trees of
nodes without thinking about ownership and everything just works sounds very
attractiv. There are a few reasons for GNUstep not to follow this l
Hello Fred,
That's a very interesting idea -- and perhaps you've already implemented it
(I've been busy with some issues with releasing our software so wasn't able to
find the time to respond sooner). And if this is how Cocoa does it then perhaps
it is what GNUstep should do, but I'm not entire
On 01.03.2012 11:08, Richard Frith-Macdonald wrote:
On 1 Mar 2012, at 09:43, Fred Kiefer wrote:
On 01.03.2012 07:34, Richard Frith-Macdonald wrote:
But these seem rather cosmetic issues ... to my mind the place
that really needs work is defining an object ownership model and
implementing memo
On 1 Mar 2012, at 09:43, Fred Kiefer wrote:
> On 01.03.2012 07:34, Richard Frith-Macdonald wrote:
>> On 29 Feb 2012, at 22:28, Doug Simons wrote:
>>> Since we've submitted the new implementation of the NSXML...
>>> classes based on libxml2 and people are beginning to use them, I
>>> thought I wou
Hi!
Am 29.02.2012 23:28, schrieb Doug Simons:
Hello,
Since we've submitted the new implementation of the NSXML... classes based on
libxml2 and people are beginning to use them, I thought I would mention some
remaining unresolved issues in the hope that other people might have more
experienc
On 01.03.2012 07:34, Richard Frith-Macdonald wrote:
On 29 Feb 2012, at 22:28, Doug Simons wrote:
Since we've submitted the new implementation of the NSXML...
classes based on libxml2 and people are beginning to use them, I
thought I would mention some remaining unresolved issues in the
hope that
On 29 Feb 2012, at 22:28, Doug Simons wrote:
> Hello,
>
> Since we've submitted the new implementation of the NSXML... classes based on
> libxml2 and people are beginning to use them, I thought I would mention some
> remaining unresolved issues in the hope that other people might have more
>
Hello,
Since we've submitted the new implementation of the NSXML... classes based on
libxml2 and people are beginning to use them, I thought I would mention some
remaining unresolved issues in the hope that other people might have more
experience with the libxml2 libraries and have some ideas a
27 matches
Mail list logo
