Jump to content


Photo
- - - - -

A horrible bug....


77 replies to this topic

#31 Glenn Meyers

Glenn Meyers

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 221 posts
  • Gender:Male
  • Location:St. Louis, MO, United States
  • Interests:I also raise African Gray Parrots and build hot rod automobiles.

Posted 18 July 2001 - 07:40 PM

Lemme see if I understand everyones position:

We should be allowed full access to the bootstraps.
We should not be allowed to make dumb mistakes.
If we are kept away from making dumb mistakes we won't need access to the bootstraps.
We should not be allowed to access the bootstraps because of the dumb mistakes we will make.
We need access to the bootstraps because of the dumb mistakes we make.
We should be allowed full access to the bootstraps.
We should not be allowed to make dumb mistakes.
If we are kept away from making dumb mistakes we won't need access to the bootstraps.
We should not be allowed to access the bootstraps because of the dumb mistakes we will make.

Hmmmmmm Houston....Another problem.....

#32 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 19 July 2001 - 06:13 AM

I think you're confusing people with multiple uses of the term 'we' in your post!

'We' the developers should have access to the bootstraps so that when something like this happens that 'we' weren't aware was possible but is because 'you/they' ProIV have made a dumb mistake and refuse to fix it.

In this case then the answer is a definate YES - 'WE' need access to the bootstraps so that we can check which functions potentially have 'your/their' dumb mistake in it.

Answer your questions?

Cheers

Mike

#33 Joseph Serra

Joseph Serra

    Advanced

  • Members
  • PipPipPip
  • 93 posts
  • Gender:Male
  • Location:Melbourne, Australia

Posted 19 July 2001 - 06:35 AM

Lemme rewrite that for you Glenn, I think you have been working too hard.


We should be allowed full access to the bootstraps.
We should be allowed to make dumb mistakes because the Gen should catch it.
Even if we are kept away from making dumb mistakes we still need access to the bootstraps.
We should be allowed to access the bootstraps because of the dumb mistakes ProIV will make.
We need access to the bootstraps because of the dumb mistakes ProIV make
We should be allowed full access to the bootstraps.
We should be allowed to make dumb mistakes because the Gen should catch it.
Even if we are kept away from making dumb mistakes we still need access to the bootstraps.
We should be allowed to access the bootstraps because of the dumb mistakes ProIV will make.
We need access to the bootstraps because of the dumb mistakes ProIV make

Houston...We have a problem...Glenn has joined those other two on Jupiter...(or does 2 = 4 now?)

#34 Tim Woodall

Tim Woodall

    Member

  • Members
  • PipPip
  • 20 posts

Posted 19 July 2001 - 07:50 AM

ProIV has been in urgent consultation with NASA to clear up this confusion and can confirm that 5 doesn't always equal 7. However they can also provide this interesting result:

Hypothesis 1=2.





 1=2(1)
Rearranging (1)2=1(2)
Adding (1) and (2)2 plus 1=1 plus 2(3)
Simplifying (3)3=3(4)


(4) is obviously correct hence Q.E.D.

On a slightly more serious note this is not a bug but is ProIV working as designed. Using DS global functions do provide a warning if you attempt anything that might have the result of redefining a literal. The only 'cost' involved in this is an 'annoying' warning if what you are doing is actually safe. Note that there is no cost at runtime.

However global logics provide a more interesting challenge. It is undecidable in general whether a given literal when passed to a global logic will be changed (although there are millions of cases where it is obvious that will/won't be). One option is to provide a warning _whenever_ a literal is passed. I doubt that many people would like this :-). A second possibility is to generate a runtime error if an attempt is made to change a literal. This might mean that people who have done dumb things but have managed to get away with it suddenly discover that their systems 'crash' after they upgrade. The third possibility (if there is another one then do tell :-) ) is to always make a copy of the literal into a scratch var before passing it to the global logic. This is perfectly feasible but, like option 2 will result in a small performance hit. For modern systems I doubt that the hit will matter/be noticable but in the past this would have been more of an issue. Note that the kernel can do any of these three options or what it does at the moment which is to give people a rope and see what they do with it :-)

Incidently, the last character of each line got cut off my previous post (Konqueror?) :-(

And something funny is being done with 'plus' signs as well.

#35 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 19 July 2001 - 08:16 AM

Tim, I think if I'd used the hypothesis to prove the hypothesis in my maths finals I probably wouldn't have managed to get a job coding in the first place.

On the ProIV side I think you missed off the final alternative - don't change the value of a literal, even if it is passed in a global interface. Global functions were intended to simplify coding (I assume, although as we are dealing with ProIV I can't be 100% sure!), hence one global is potentially going to be used in a lot of functions. If you then change a purely 'I'nput parameter to be 'B'oth ways because you need it in most of your functions it should not then change the value of 0 in the other functions. I realise that all functions using the global should then be tested but lets face it, this isn't the sort of bug that's always immediately obvious, even with thorough testing. I could knock up a quick utility to make sure it's not happening anywhere, oh no, I forgot - no bootstraps...

I'm perfectly willing to concede that ProIV shouldn't have to watch our backs if we're going to do stupid things (as you can apparantly do this in a global logic as well I would consider that stupid as it would be pretty much typing 1 = 2 into your code!). The fact remains though that stupid things like this keep popping up and:

a) ProIV always refuse to conced that there is a problem, and hence it will never get fixed.
:) We don't know how many more things like this there will be - this one isn't a problem for us now that we know about it but what else is lurking in future kernel releases waiting to rear its ugly head?? At the moment we can do a quick scan of the bootstraps and see if we have any problem functions. Post version 5 we are theoretically stuffed!

Cheers

Mike

#36 Stuart Burton

Stuart Burton

    Advanced

  • Members
  • PipPipPip
  • 71 posts
  • Gender:Male
  • Location:Luton, United Kingdom

Posted 19 July 2001 - 08:26 AM

Jeez...How many posts is it going to take for this point to be conceded? The bootstraps are essential to anyone supporting a customer site or a development environment.

I have lost count of the number of times that access to the bootstraps has saved me literally HOURS of development time. Do we now have to explain to our customers (you know, the people who pay for our houses, cars and beer?) that the kind of work that used to take a couple of minutes now will take a whole lot longer? How long do you think Pro-IV in any guise will last when customers find out that it is no longer the RAD tool it purports to be?

BTW, the side-effect of constants being changed by a function is a well documented feature of call-by-reference if you want to get all computer-sciencey-geeky, but come on! We are are working in the real world and this kind of problem should be taken care of (ie a gen time error). Sitting around discussing it and trying to justify what is in actual fact a BUG, is nothing but verbal masturbation.

Just fix it.

#37 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 19 July 2001 - 08:28 AM

Bit difficult for me to find that bug because I dont have a linux machine.

I'll try to find one that I can use to test it. Konqueror is probably executing JavaScript differently than on Windows.

Normally, I only test on IE,Netscape and Opera. The problem is that all browsers behave differently and I have to have lots of 'if' statments depending on the browsers.

Rob D

#38 Tim Woodall

Tim Woodall

    Member

  • Members
  • PipPip
  • 20 posts

Posted 19 July 2001 - 09:48 AM

>Tim, I think if I'd used the hypothesis to prove the hypothesis in my maths finals I probably wouldn't have managed to get a job coding in the first place.

Fortunately, I'm a physics graduate and so resort to the 'and so, due to the uniqueness theorem (which the mathematicians can prove) ...' :-) although I do know what is wrong with my 'proof'

>On the ProIV side I think you missed off the final alternative - don't change the value of a literal, even if it is passed in a global interface.

I don't really understand this. All ProIV values are passed by reference, even literals and therefore it is theoretically possible to redefine a literal (practically in this case as well). Are you saying that the developer shouldn't change the value of the literal - isn't that the situation we have at the moment? Going back to the top of the thread, this is an inherent feature of pass by reference. Different languages have different work arounds but if you have pass by reference then you potentially have this problem.



> If you then change a purely 'I'nput parameter to be 'B'oth ways because you need it in most of your functions it should not then change the value of 0 in the other functions. I realise that all functions using the global should then be tested but lets face it, this isn't the sort of bug that's always immediately obvious, even with thorough testing. I could knock up a quick utility to make sure it's not happening anywhere, oh no, I forgot - no bootstraps...

I don't completely follow this. Are you saying that for all possible ProIV functions you can determine whether a literal will be changed? You are the mathematician but I think you will find this comes under the category of undecidable. Part of the problem occurs because ProIV utilises constant folding, i.e. only stores a constant once if it is used multiple times within a function. This of course saves disk space (and memory) but even if ProIV didn't do this you could still achieve the equivalent of 1=2 but it would be slightly more difficult. This constant folding was the basis of the C quirk I posted earlier.

OTOH, if what people are saying is that there are Bootstrap functions that will redefine literals when you pass literals to them that aren't documented as changing the values passed to them then I would accept that this is a bug (maybe in documentation) and should be fixed. (Note that this is a bug regardless of whether you pass a literal or a variable. Changing a literal is just more emotive :-) )

> a) ProIV always refuse to conced that there is a problem, and hence it will never get fixed.

No, this is a problem it is just that every possible solution has its drawbacks. If we could change things and not have to worry about the possibility of breaking currently working systems then all would be fine. After all, why are people reluctant to upgrade their systems every time a new proiv version comes out? I think we can say that breaking code that relies on the fact that you can redefine literals is ok. Breaking code that changes literals but then never reuses them is a grey area. The code works - is it broken? As I stated before, copying the literals is the only obvious solution (other than do nothing). It only breaks the code that relies on being able to make 1=2 but does involve some performance drop albeit small. There is also a small amount of memory used - negligible today but significant in the past.

#39 Tim Woodall

Tim Woodall

    Member

  • Members
  • PipPip
  • 20 posts

Posted 19 July 2001 - 10:04 AM

> We are are working in the real world and this kind of problem should be taken care of (ie a gen time error).

Unfortunately the ProIV developers are working in the real world and so can't[1] make this a gen error. They could make it a run-time error or pass a copy of the literal and finesse the problem.


[1] This solution to the problem is fundamentally undecidable. See any good text on algorithimic complexity for further details.

#40 Guest_Bill Gates, Windows Overlord_*

Guest_Bill Gates, Windows Overlord_*
  • Guests

Posted 19 July 2001 - 10:12 AM

Under my personal instructions, this site is designed only to deal with Windows Explorer. Forcing customers to use only one utility is the future.

If you or other companies wish to write other utilities, don't complain when things go wrong. My software is the best in the world and my team are the only people capable of writing such software.

Any problems you encounter are not bugs, they are design features. Live with it or change - it's your choice.

#41 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 19 July 2001 - 10:22 AM

Aargh, physicist alert - are we just approximating 1 to zero then ;-)

There seems to be some confusion as to exactly what problems we (or at least I) have with this situation and how to sort it:

1. This bug doesn't really bother me now as I know about it and can avoid it in future. What annoys me is that ProIV won't concede it's a bug.

2. If I have access to the bootstraps when we discover something like this then I can check thrugh and see if any functions pass values back into a literal in the calling function - then I can give those functions some special attention and see if they are likely to cause problems. Without the bootstraps I need to go through every function in the system - not entirely practical on a large system.

3. If ProIV don't think 1=0 is a problem what else won't they think is a problem and we'll have to discover for ourselves. Then we're back to the situatiuon in point 2 where we can't search the bootstraps to find other functions that might have a similar problem.

Basically it boils down to 1 thing - ProIV don't listen to the people actually using their software.

Cheers

Mike

Campaign for Relevant Access Permissions (Bootstraps Identify The Crap Hassles!!)

#42 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 19 July 2001 - 10:51 AM

'The ProIV development team are working in the real world' might be undecidable but whether or not it is possible to make this a gen error shouldn't be. If it is undecidable within the 'ProIV kernel' axiom system then perhaps you need to expand the system...

Cheers

Mike

#43 Stuart Burton

Stuart Burton

    Advanced

  • Members
  • PipPipPip
  • 71 posts
  • Gender:Male
  • Location:Luton, United Kingdom

Posted 19 July 2001 - 11:04 AM

Yes this can be made a gen time error. It should be illegal for literals to be passed to a global function where the parameter is defined as 'B' or 'O' mode.

Or perhaps this is just too simple....

#44 Tim Woodall

Tim Woodall

    Member

  • Members
  • PipPip
  • 20 posts

Posted 19 July 2001 - 12:18 PM

Please!

> 'The ProIV development team are working in the real world' might be undecidable but whether or not it is possible to make this a gen error shouldn't be. If it is undecidable within the 'ProIV kernel' axiom system then perhaps you need to expand the system...

IF #VAR1 = 1 THEN
#VAR2 = 2
ENDIF

If VAR2 is an alias to a literal and VAR1 was retrieved from a database then should this generate a gen error? What about if the database has a constraint such that VAR1 can never equal 1?

> Yes this can be made a gen time error. It should be illegal for literals to be passed to a global function where the parameter is defined as 'B' or 'O' mode.

B and O mode give a warning in DS and, I assume, will give a warning in VIP. ProIV could change that warning into an error but all that will achieve is preventing the rare case when it actually makes sense from working!

Global Logics are a different matter and it is _IMPOSSIBLE_[1] to generate a gen error without having some cases that should be allowed rejected. I'm sorry but this is a fundamental limitation in mathematics/the universe. A runtime error is possible and a (invisible) copying of the literal at runtime to finesse the problem is possible.

[1] It is theoretically possible to enumerate every possible ProIV program and probably also to decide whether each of them do/don't have this problem. This is because computers don't have infinite tapes (memory) to use but the problem is impossible in practice.

#45 Stuart Burton

Stuart Burton

    Advanced

  • Members
  • PipPipPip
  • 71 posts
  • Gender:Male
  • Location:Luton, United Kingdom

Posted 19 July 2001 - 12:46 PM

>B and O mode give a warning in DS and, I assume, will give a warning in VIP. ProIV could change that warning into an error but all that will achieve is preventing the rare case when it actually makes sense from working!B)



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users