Two problems introduced by Update 5

[saimo]

Making tests on a fresh installation is useless not only because of the reasons already explained, but also because AmigaOS is a product that will end up in the hands of many (and lets hope lots of) people, and each and every one will have a system of his own, in one way or another: AmigaOS will have to be robust to perform as well as possible under the most disparate conditions - operating correctly when freshly installed is only the starting point.

Of course noone expects all users to refrain from customising their installed system, and ideally AmigaOS should function equally well on them all. But in practice, we beta testers cannot possibly cover testing with all the possible permutations of programs installed, settings changed and hardware connected etc. So when an update is nearing release, the focus is on testing it with a virgin setup, so that we have a common firm ground where we "know" things should work.

I think I didn't express well myself there.
I did not mean there should not be a common starting point (it can't be otherwise, of course), nor that betatesters should cover all the possibilities (which would be impossible even with an enormous number of betatesters).
I meant that since the actual systems of users differ from the default installation, the system has to be able to cope with variations. In this case, my system represents an "interesting" variation that could provide good information for the improvement of the OS: ignoring such system and making tests on a fresh installation would be an improductive move (I've said more about this in an earlier post, so I won't repeat the same stuff over and over again). Not to mention that, precisely because betatesters can't reproduce all the possible conditions, it wouldn't be even wise.

So the reason for asking for a test with a fresh installation is to compare with what we tested (and/or can test again) on our own systems.

Sorry, but this does not make sense: if I install the OS from the scratch, the problem won't be there; moreover, there's not much to compare between a fresh installation made by me and a fresh installation made by somebody else.
(This has to be considered together with the next comment.)

Now there are two possibilities. One is that it works under the fresh installation, in which case we have to start installing and modifying step by step until we find the item which has some sort of problem with the update. The other is that it still doesn't work, and then we will have to look at things like hardware setup (maybe finding a beta tester who can duplicate that setup and - hopefully - reproduce the problem).

On a fresh install MultiView will work because:
* it is known to work;
* it's unrealistic to think that there is a hardware-related problem that affects only the copy&paste functionality of MultiView.

Absolutely. But we need to be able to reproduce it on a beta tester's (or even better, the relevant developer's) system, and that requires isolating the relevant part of the setup which makes the problem appear or disappear.

That's why I'm making tests...

Of course this could theoretically also be done by removing stuff step by step from your system, until copy/paste works,

As reported earlier, after booting without startup-sequence, MultiView doesn't work already: there's not much left to remove
Now it's a matter of considering the components used by MultiView (especially relatively to the copy&paste functionality): a just kickstart-booted system should simplify the hunt.

[saimo]

chris, I just realized I had missed this post of yours...

The rendering is handled by the DataTypes object itself. They are BOOPSI objects and can be attached to windows, rendered and interacted with just like any other BOOPSI gadget. Rendering is usually handled by the superclass (in this case, text.datatype)

Thanks for the explanation.
I must say I'm surprised. But then, on second thought, I guess it's normal to provide a default method to "output" the data.
Does the rendering also contemplate the highlighting? (But GUI rendering still sounds a bit too much to me.)

ascii.datatype 53.3 (12/30/2011)

Oh, maybe it was that and not text.datatype that was in update5. Which version of text.datatype do you have?

Now I'm not on the A1 - I will check tomorrow and let you know.

[Belxjander]

chris, I just realized I had missed this post of yours...

The rendering is handled by the DataTypes object itself. They are BOOPSI objects and can be attached to windows, rendered and interacted with just like any other BOOPSI gadget. Rendering is usually handled by the superclass (in this case, text.datatype)

Thanks for the explanation.
I must say I'm surprised. But then, on second thought, I guess it's normal to provide a default method to "output" the data.
Does the rendering also contemplate the highlighting? (But GUI rendering still sounds a bit too much to me.)

ascii.datatype 53.3 (12/30/2011)

Oh, maybe it was that and not text.datatype that was in update5. Which version of text.datatype do you have?

Now I'm not on the A1 - I will check tomorrow and let you know.

With the way intuition works it is entirely plausible to have the DataType include output rendering code

The problem is how complex is the data and can you OOP classify all of it? DataTypes more suffer from there being no logical limits within the OS design

What stops recursion when embedding?

The only extension I see any need for is some kind of stateful stream block handling which would allow them to be used as an Amiga OS specific codec system

[saimo]

With the way intuition works it is entirely plausible to have the DataType include output rendering code

The problem is how complex is the data and can you OOP classify all of it? DataTypes more suffer from there being no logical limits within the OS design

What stops recursion when embedding?

The only extension I see any need for is some kind of stateful stream block handling which would allow them to be used as an Amiga OS specific codec system

I hope you don't mind if I don't comment, as it's way OT - it wouldn't be any good if the problems got forgotten

Thanks anyway, also because your post reminded me that I was supposed to post the version of my text.datatype - here it is: 53.5 (05/01/2011).

[Belxjander]

With the way intuition works it is entirely plausible to have the DataType include output rendering code

The problem is how complex is the data and can you OOP classify all of it? DataTypes more suffer from there being no logical limits within the OS design

What stops recursion when embedding?

The only extension I see any need for is some kind of stateful stream block handling which would allow them to be used as an Amiga OS specific codec system

I hope you don't mind if I don't comment, as it's way OT - it wouldn't be any good if the problems got forgotten

Thanks anyway, also because your post reminded me that I was supposed to post the version of my text.datatype - here it is: 53.5 (05/01/2011).

No problem at all ... I just hope the problem can be resolved as I also have the same two problems annoying me

[saimo]

No problem at all ... I just hope the problem can be resolved as I also have the same two problems annoying me

Ah, I "nice" to hear that I'm not the only one: it means that my system is not that unique and that it should be easier to reproduce the problems on other systems.

[Belxjander]

No problem at all ... I just hope the problem can be resolved as I also have the same two problems annoying me

Ah, I "nice" to hear that I'm not the only one: it means that my system is not that unique and that it should be easier to reproduce the problems on other systems.

I am also going to walk through what Kickstart modules affect intuition as I made a change to how I install updates

I install to a base folder which is always a fresh copy of the last installed update and have preset the comments making it really easy to back trace anything

I will postwhat I can find out

--- update ---

I can paste but not select or copy from a shell and in multiview I have no problem drag selecting


I have the samebehavior in update 4 as well

[saimo]

I can paste but not select or copy from a shell

The user-level cause of this has already been identified: smart refresh in conjunction with compositing (see previous posts).

and in multiview I have no problem drag selecting

Ah, then the two problems you were talking about are not the two I have (the second was the delays in make).

[chris]

Does the rendering also contemplate the highlighting? (But GUI rendering still sounds a bit too much to me.)

It must do, as Multiview does not do any rendering of its own beyond attaching the DataTypes object to the window AFAIK.

[Belxjander]

I can paste but not select or copy from a shell

The user-level cause of this has already been identified: smart refresh in conjunction with compositing (see previous posts).

and in multiview I have no problem drag selecting

Ah, then the two problems you were talking about are not the two I have (the second was the delays in make).

I use smart refresh without composition

I will try the other way of simple refresh with composition

as for the other problem?