ScriptVM, a script language

DominiqueB · Post by **DominiqueB** » Fri Apr 23, 2004 6:59 pm

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.

fsw · Post by **fsw** » Fri Apr 23, 2004 8:34 pm

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

Brice Manuel · Post by **Brice Manuel** » Sat Apr 24, 2004 9:10 pm

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".

thefool · Post by **thefool** » Sat Apr 24, 2004 9:51 pm

Well, since the change dont take long time to fix on even big programs its not a big deal. Its just a few commands.

fsw · Post by **fsw** » Sat Apr 24, 2004 9:59 pm

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

Brice Manuel · Post by **Brice Manuel** » Sat Apr 24, 2004 10:28 pm

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.

thefool · Post by **thefool** » Sat Apr 24, 2004 10:33 pm

removing UpdateStatusBar() and removing the memory id isnt a big deal..

Brice Manuel · Post by **Brice Manuel** » Sat Apr 24, 2004 10:42 pm

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?

thefool · Post by **thefool** » Sat Apr 24, 2004 10:57 pm

Well, i have been using pb for about 8 months, and i think this is the first time it happens.

LarsG · Post by **LarsG** » Sat Apr 24, 2004 11:38 pm

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..

Post by **Dare2** » Sun Apr 25, 2004 12:26 am

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

Post by **freak** » Sun Apr 25, 2004 12:28 am

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

Brice Manuel · Post by **Brice Manuel** » Sun Apr 25, 2004 4:27 am

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

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

LarsG · Post by **LarsG** » Sun Apr 25, 2004 8:54 am

Fr34k: you're making me drool just thinking of what 4.0 will introduce.. (read: break code for better features

)

blueznl · Post by **blueznl** » Sun Apr 25, 2004 3:15 pm

if v4 contains all my wishlist items you're free to break more, just not my fingers...

PureBasic Forums - English

ScriptVM, a script language

Answer: