Page 3 of 6

Answer:

Posted: Fri Apr 23, 2004 6:59 pm
by DominiqueB
Your procedure is declare as returning a byte by using a .b
Then if you whant to return an adress that is what * means,
you must declare your procedure as proc.l because an adress is a long var.

That's all, i think.

Dominique.

Posted: Fri Apr 23, 2004 8:34 pm
by fsw

Code: Select all

Procedure.b FPeekB(Address.l)
  *PtrB.BYTE=Address.l
  ProcedureReturn *PtrB\b
EndProcedure 
This code is from scripvm.pb and it works with 3.81.

It also crashes on ProcedureReturn if you make:

Code: Select all

Procedure.b FPeekB(Address.l)
  *PtrB.BYTE=PeekB(Address.l)
  ProcedureReturn *PtrB\b
EndProcedure 

Posted: Sat Apr 24, 2004 9:10 pm
by Brice Manuel
This code is from scripvm.pb and it works with 3.81.
That code is not compatible with the new version of PureBasic. The new version of PureBasic broke the #1 rule of developing a programming language, and that is do not make changes to the language that will break your user's existing code.

I have only been using PB since Christmas and just recently started porting my C++ Builder projects over to PB so the new changes are not a big deal to me, but I imagine for those who have been using PB a lot longer, it is a big deal, not to mention all the code over at PureArea that has now become "broken". :(

Posted: Sat Apr 24, 2004 9:51 pm
by thefool
Well, since the change dont take long time to fix on even big programs its not a big deal. Its just a few commands.

Posted: Sat Apr 24, 2004 9:59 pm
by fsw
Brice Manuel wrote:
This code is from scripvm.pb and it works with 3.81.
That code is not compatible with the new version of PureBasic. The new version of PureBasic broke the #1 rule of developing a programming language, and that is do not make changes to the language that will break your user's existing code.

I have only been using PB since Christmas and just recently started porting my C++ Builder projects over to PB so the new changes are not a big deal to me, but I imagine for those who have been using PB a lot longer, it is a big deal, not to mention all the code over at PureArea that has now become "broken". :(
Yeah,
but do you know what the worst part is :?:

Nobody of THE MAKERS tells you WHY it is "broken" 8O

Posted: Sat Apr 24, 2004 10:28 pm
by Brice Manuel
Nobody of THE MAKERS tells you WHY it is "broken"
I have to admit this is making me reevaluate using PB. If in the few months I have been using it, they are already changing things and breaking existing code, I am not sure I am willing to trust that four more months into my project, I will not have to be doing rewrites to fix more code that has become obsolete overnight.

Posted: Sat Apr 24, 2004 10:33 pm
by thefool
removing UpdateStatusBar() and removing the memory id isnt a big deal..

Posted: Sat Apr 24, 2004 10:42 pm
by Brice Manuel
removing UpdateStatusBar() and removing the memory id isnt a big deal..
The recent changes do not affect me, but being new to PB, I am just worried that "if" this is a habitual issue with PB, how bad will the changes be next time around?

Posted: Sat Apr 24, 2004 10:57 pm
by thefool
Well, i have been using pb for about 8 months, and i think this is the first time it happens.

Posted: Sat Apr 24, 2004 11:38 pm
by LarsG
I see it this way (as I've said before):

If it is critical that your code don't break, then use PB v.3.81.. there's nothing wrong with this version..

However; If you don't mind changing a couple of lines in your program, *or* if you start a new project, then you should use the latest version, v. 3.90...

This new version has introduced some features that needed a lot of rewriting of the core, and at some point, something "had" to be broken.

Still, I think it is for the better, and will in the future make PB more great than it already is..

note: above is my 2 cents.. :D

Posted: Sun Apr 25, 2004 12:26 am
by Dare2
LarsG is right.

I reckon this is the best time for PB to have other radical changes done, rather than down the track when everyone is settled. If noses are going to get out of joint, why have it happen twice?

Sometimes products may need to break, to move on. Or they stagnate.

Perhaps as a comparision, think v3.8 - 3.9 and VB - VB.net

Posted: Sun Apr 25, 2004 12:28 am
by freak
No, this thing is not common to every PB update. We try to avaoid it
wherever possible.
We don't breake code for fun, it was really neccesary this time.

But to be honest, you will have to expect some more of these things for
the v4.0 release.
This is because the goal is, to change everything that HAS to be changed
till then, so that after 4.0, this kind of thing doesn't need to happen again.
We of course try to keep it to a minimum, but some changes might be
neccesary.

Timo

Posted: Sun Apr 25, 2004 4:27 am
by Brice Manuel
Well, i have been using pb for about 8 months, and i think this is the first time it happens.
That is reassuring to us newcomers :wink:
ut to be honest, you will have to expect some more of these things for
the v4.0 release.
This is because the goal is, to change everything that HAS to be changed
till then, so that after 4.0, this kind of thing doesn't need to happen again.
Sounds like 4.0 is going to bring some awesome new stuff 8O

Posted: Sun Apr 25, 2004 8:54 am
by LarsG
Fr34k: you're making me drool just thinking of what 4.0 will introduce.. (read: break code for better features :P)

Posted: Sun Apr 25, 2004 3:15 pm
by blueznl
if v4 contains all my wishlist items you're free to break more, just not my fingers...