Oxygen Basic

Programming => Example Code => Data Processing => Topic started by: Aurel on May 20, 2014, 01:16:24 PM

Title: Bytecode Interpreter concept
Post by: Aurel on May 20, 2014, 01:16:24 PM
Hi to all... :)
For a start i will present here Ed Davis (our member) toy2....(i am not sure if name is right)
bytecode interpreter which he present in C,euphoria,VB script, qb64 and in FreeBasic version.
(Ed ..if i miss something ..let me know  ;) )

Ok here is FB version which i would like to convert to Oxygen Basic....


.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 20, 2014, 01:35:35 PM
Thanks Aurel,

...which i would like to convert to Oxygen Basic....
... and you have already made your first step in that direction: you've changed the file extension to .o2bas. ;D
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 20, 2014, 02:19:39 PM
Ahh yes ...that is how editor save file ,and nothing else.
Also i am looking agian in DLib -source code file called parser
which is suposed to be source file -> bytcode file translator... ::)
Hmmm concept is very different with a PB awkward syntax...
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 21, 2014, 03:33:12 AM
Hello Aurel,

Let us concentrate on toy2 first, OK? It will be easier to talk about extending it after it's been ported to O2.

Can you also provide the C language version of it, please?
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 21, 2014, 05:38:15 AM
sorry Mike...i don't have C version but Ed have and maybe he can provide link to file
from QDepartment site ,,I cannot get this file because is something wrong with my yahoo
account.. :-\
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 21, 2014, 06:50:30 AM
Forget it Aurel,

It isn't really necessary - the code is very straight-forward and can be ported to C as easily as to O2 with just two additional user functions, mid() and right().
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 23, 2014, 04:22:25 PM
Hello Aurel,

I've got toy2 working in FBSL's BASIC so there won't be any problem to port it to Oxygen now.

Stay tuned.

.
Title: Re: Bytecode Interpreter concept
Post by: JRS on May 23, 2014, 06:00:12 PM
You have my ear when you get to the string handling part.

Attached is all the Toy files from QDepartment.


.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 23, 2014, 08:40:55 PM
Hi Mike...
That is good ...
But where is the source ?
I would like to try FBSL version  :)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 05:09:55 AM
Hi John,

Thanks a lot for this zip. I have a very old Yahoo account that doesn't work for new Yahoo services like QDepartment. I guess that's also the case with Aurel's account. Now I will also be able to try Ed's C version with my Dynamic C. His C version has a slightly different implementation but at a first glance, it should work out of the box too.

Hi Aurel,

Here comes the zip with the FBSL source script, precompiled executable, and test script primes.toy. You can execute the task in several different ways:

1. by dragging-and-dropping primes.toy on toy.exe;
2. if you have Fbsl.exe v3.5 associated with .FBS script files, by double-clicking on toy.fbs and entering the name of primes.toy into the console if primes.toy is in the same directory as toy.fbs, or a full pathname of primes.toy, if it is stored in some other directory; and
3. by opening up your shell console and dragging-and-dropping into it successively (with spaces in between!) your existing Fbsl.exe v3.5 file, the toy.fbs script file, and finally, the primes.toy test file and then hitting Enter to execute the bunch.

And of course, you can also execute toy.fbs from your Eclecta editor and enter the name of primes.toy into the console as described in Item 2 above.

.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 24, 2014, 10:12:44 AM
Thanks Mike  ;)
Works fine
Mike is this exe with dynC or pure FBSL?
I have try with 10000 iteration which need cca 4 sec and it looks to me like the
same result i get with FreeBasic version.
I would like to crete non-console o2 version with a 'dirty hack' editor  :D
ok thanks again  ;)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 11:56:28 AM
You're welcome Aurel,

And no, this isn't DynC. This is FBSL's interpretative BASIC - toy.fbs "compiled" into a usual FBSL executable. I haven't yet tried Ed's C version in FBSL DynC but I'm sure it'll run a few dozen times faster than this script. I think the FreeBASIC version in fact runs also much much faster than it seems.

Anyway, you can time it yourself adding the following lines

.............
dim gtc = GetTickCount()
interpret()
print "completed in ",  (GetTickCount() - gtc) / 1000, " seconds"
.............

to sub main() to measure the exact time it takes to find, say, 10000 primes. You can also add similar timing to the FreeBASIC script in its sub main() using its Timer and Print keywords and recompile the script to see the real benchmark figures. Make sure your FbEdit Options->Build Options->Command contains the fbc -lang qb -s console parameters when recompiling it.

In either case, the bottleneck will be the Print statement which is rather slow and unpredictable speed-wise in every language. The arithmetics loop proper will run much faster without it and you can only let primes.toy print the last result to the console so that you can check if the code runs properly in the both languages you're trying to compare.

Finally, the "dirty hack" isn't so good for line parsing as it may seem at a first glance - it is very slow while doing it. Oxygen has a built-in getfile() function which is similar to FBSL's FileGet(BINARY). And you can use an Oxygen equivalent to my function get_line() (the bottommost function in the toy.fbs script) to parse the code buffer into successive code lines. This will be much faster than calling the richedit control to yield its lines of text. Richedit has to do quite a lot of conversion internally before it can give you what you want. :)
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 24, 2014, 12:57:09 PM
Interesting thread for reading.  I don't have access to a Windows machine, so I can't test anything.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 01:22:52 PM
BTW Aurel, now that I'm looking into my get_line() again, it doesn't seem very nice to me any more. It contains bloat left over from my earlier variants tested for the optimum strategy.

The following would be a neater one, of course, in terms of conventional BASIC syntax (FBSL can be much more laconic than that):

function get_line() as string // PARSE CODE BUFFER INTO SUCCESSIVE LINES
   static head as long = 1
   dim tail as long
   dim ret as string
   
   tail = instr(code, crlf, head, true)
   ret = mid(code, head, tail - head)

   if ret = "" then return "<eof>"
   head = tail + 2

   return ret
end function
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 01:40:39 PM
Kuron,

FBSL v3.5 runs well enough in Wine v1.7 under Linux and Mac OS X too. :)
Title: Re: Bytecode Interpreter concept
Post by: JRS on May 24, 2014, 01:44:10 PM
Quote
Interesting thread for reading.  I don't have access to a Windows machine, so I can't test anything.

Wine is a good option if you wish to run OxygenBasic under Linux. VMWare Workstation for the Mac.
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 24, 2014, 01:51:46 PM
Kuron,

FBSL v3.5 runs well enough in Wine v1.7 under Linux and Mac OS X too. :)

According to the license, I need to purchase a license, but can't find any info on the price.


Quote from: John
Wine is a good option if you wish to run OxygenBasic under Linux. VMWare Workstation for the Mac.

I haven't tackled Wine yet.  I am still learning the ins and outs of Linux.  Unfortunately, life got in the way a bit.  ;)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 02:12:22 PM
According to the license, I need to purchase a license, but can't find any info on the price.

I don't have the slightest notion of what you're talking about. FBSL is absolutely free (http://www.fbsl.net/phpbb2/viewtopic.php?f=23&t=2985) for non-commercial use. Neither is it nagged, feature depleted, or restricted to any trial periods whatsoever.

We charge for commercial support only. And of course, we're open to donation and sponsorship. :D
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 24, 2014, 02:19:44 PM
Quote
The program is provided as FREEWARE but does require a license if used or distributed by commercial companies or if used for developing commercial products

Based on your own info, I require a license if I were to ever use it.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 03:23:23 PM
Exactly. You may not use it in a commercial environment. You're not supposed to use FBSL for resolving your business tasks or to even have it installed on your office computer unless you have negotiated such a possibility with the FBSL copyright owner.

FBSL has been primarily designed for education, self-education, and fun.

I can however reassure you. When FBSL v3.5 Final is out, it will have a much more permissive license enabling you to use it for any legal purpose without restriction, including its use in business environments or for developing commercial projects.

Are you really so much a legal entity here anyway rather than just a hobbyist BASIC pragrammer, Brice? :)
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 24, 2014, 03:37:55 PM
Quote
And of course, you can also execute toy.fbs from your Eclecta editor and enter the name of primes.toy into the console as described in Item 2 above.

Mike
And here we are with a problem .
When i tried to click any runthis file or anything in Eclecta then nothing heapend...
why?
I downlad last release of FBSL from FBSL forum
and seems to me that everything is ok ...
but i get only this :::
 

.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 24, 2014, 03:47:51 PM
As an immediate cure to your problem, click the yellow |> button to run any script that hasn't been selected as the startup script (i.e. as the main project file in an FBSL multi-file project). Make sure you have the path to your Fbsl.exe v3.5 RC2 selected and saved in the Executable: field in the Tools->Code Editor Options...->Environment tab of the Options dialog.

Also, please read carefully this thread (http://www.fbsl.net/phpbb2/viewtopic.php?f=22&t=3015) on the FBSL forum. This is the most detailed step-by-step installation and operating manual for FBSL v3.5 Release Candidate 2 that I was ever able to write. I can not describe the process of installing and using this Beta release of FBSL any better than that.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 24, 2014, 11:02:37 PM
Hi Mike..
Sorry man but i must to say that something is wrong with Eclecta.
When i set path to proper location and save then restart eclecta again ..
same problem stay...editor simply not want to send comand line to fbsl.
And theme sandy sahara refuse to colorize anything in toy.fbs
but other theme works but compile buttons not ...
ok..
do i can try use older version of Eclecta with this new rc fbsl?

PS. fbsl code is far easier to me to read  ;)
I will try run interpreter with my editor.
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 25, 2014, 01:28:48 AM
I can however reassure you. When FBSL v3.5 Final is out, it will have a much more permissive license enabling you to use it for any legal purpose without restriction, including its use in business environments or for developing commercial projects.

Good to know.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 02:47:13 AM
Hi Aurel,

What type of Eclecta are you trying to use? There are two: one comes as separate project files similar to the old Eclecta script, but the other one in the \Bin directory is a precompiled executable with its own set of .BMP resources and an own .INI file. They do not affect each other. The precompiled one is independent and portable: you can even copy it with its .INI and .CHM files and resource subfolder to a flash stick and carry around in your pocket and use when needed.

You are the first person in over a half-thousand other people to report Eclecta inoperative. Perhaps you still didn't follow the installation instructions correctly. You must have a clean, full and working v3.4.10 installation of FBSL on your computer and you must at least copy the \FBSLv3 folder from the RC2 zip over the old v3.4.10's \FBSLv3 folder letting Windows overwrite the older files when it asks you to. Then just specify the correct paths for the precompiled Eclecta executable and use it for all your operations with the new FBSL v3.5 files. The old FBSL v3.4.10 installation package is downloadable from Gerome's signature on the forum. Do not use the ancient packages from any other sources on the net!

You can use an older version of Eclecta only if you precompile it with FBSL v3.4.10 into an executable because the deprecated syntax of its source file isn't compatible with FBSL v3.5. However when using it, you won't be able to colorize or format DynAsm and DynC blocks at all and you will still have all the other glitches that have been fixed in Eclecta v1.1.15 in recent years.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 07:47:03 AM
Mike
I am using precompiled version of Eclecta from bin folder.
As you can see on screenshot i constantly receive this error message.
About old version ...no i use this new one RC2 which i download from FBSL forum
What ever i do i cannot force Eclecta to run file ... :-\

Do you can tell me what is [scriptparameters] i see this when i run FBSL.exe.
I need this to try run ( execute code ) from my (fbsl-mod) editor.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 08:01:23 AM
Mike
In addition to my prefered 'dirty hack'...no this time is not .
I just modify AsciEdit version that can work with FBSL files
so nothing advanced or ultra special.
Unpack content into main FBSL folder (where is FBSL.exe)
because editor must be in this folder ...
And voila ....everything work at once ... :D

Sorry man i still connot figured why Eclecta not work for me.

.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 08:20:26 AM
No problem Aurel,

If you're happy with AsciEdit and got it working with FBSL scripts, then it's all right by me. For all it's worth, you can even use your Notepad to edit them, and double click them with your mouse, to run.

We will come back to that issue again only when FBSL v3.5 Final is out with its own installer and only if it still doesn't work for you again.

Title: Re: Bytecode Interpreter concept
Post by: JRS on May 25, 2014, 08:46:12 AM
I think it should be standard practice to allow Aurel to try to install your software before any release. I'm glad SB wasn't the only BASIC that didn't pass the Aurel test.

 
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 25, 2014, 08:56:29 AM
Mike:  is there an ETA for FBSL v3.5 Final?

I think it should be standard practice to allow Aurel to try to install your software before any release.

 ;)

Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 09:39:03 AM
Hi Kuron,

It had been scheduled for mid-April before I was laid up with flu and also before that bloody horror started in Ukraine. The both dramatic developments spoiled my productivity and ruined my plans seriously and now I'm still catching up very slowly with my schedule. I have yet a large piece of FBSL BASIC manual to write and about a hundred samples to update.

At any rate, now I'm planning to have it all ready for publication by the end of July at the most. This is when I'm supposed to change my current place of residence for the city of Minsk again; this is when I'll be completely off the air for about 10 days or so.

I'm going back to my last harbor, gentlemen. :)
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 10:57:46 AM
Hi Mike
After quick look in Eclecta source code i don't see how 'yellow button'
trigg compile script subroutine.
Do you can point me where to look?
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 11:05:48 AM
Just a moment Aurel,

I need some time to have a look.

And you'll have to wait a little more for an Oxygen version of Toy interpreter. Oxygen memory allocation is still too buggy for that.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 11:18:01 AM
Hello Aurel,

Clicking the yellow button activates the event that is described in the file Events.inc, line 892, CASE IDM_RUNFILE.

Same old ShellExecute() that you're so fond of:

....................
ShellExecute(0, NULL, LEFT(exepath, STRLEN(exepath)), _
LEFT(FileName, STRLEN(FileName)), "", SW_SHOWNORMAL)
....................


Your FBSL executable must be called Fbsl.exe and your .FBS file extension must be associated with that executable. This is done by the installer when you install the old FBSL v3.4.10. If there's no such association or if you named the new Fbsl.exe RC2 to some other name, then of course ShellExecute() will not work.

:)
Title: Re: Bytecode Interpreter concept
Post by: JRS on May 25, 2014, 11:36:23 AM
It's becoming painfully obvious that if you want to get people to try your software a flawless install is a prerequisite. (make a fool out of the user after they have the software installed.  ;D )
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 11:54:02 AM
John,

This is a beta release. If a newcomer wants to try out FBSL, they can and should start with the stable (well, not any more by RC2 standards, of course) release of v3.4.10. It has a full-fledged installer and it works out of the box and there is still a lot to FBSL that can be learned from it.

There are a few very able FBSL coders who have formed the real tester team for v3.5 from its very early Alpha, and this is who the current RC2 primarily targets.

As soon as Final is ready, it will have its own installer and v3.4.10 will become part of FBSL's long-time history.

Aurel could have been part of that team too had he not stopped learning FBSL and abandoned it in favor of trolling at alien sights about matters far beyond his comprehension. For which he was of course mercilessly banned from the FBSL forum.
Title: Re: Bytecode Interpreter concept
Post by: JRS on May 25, 2014, 01:14:36 PM
Quote
For which he was of course mercilessly banned from the FBSL forum.

What does banned mean?  :P

Would you like to see my trophy room of shrunken skulls?
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 01:47:30 PM
OMG
For ultrasmart->mister John
RC2 version of FBSL is a portable version...soooo
there is no installer and that is not problem....


 
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 01:59:44 PM
What does banned mean?

Getting banned (to ban-banned-banned (http://www.merriam-webster.com/dictionary/ban)) means when someone with administrative rights baseball-bats your skull with all his might off the forum and follows it with his eyes until it gets shrunk (to shrink-shrank-shrunk (http://www.merriam-webster.com/dictionary/shrink)) to nothingness beyond the horizon.

I'm also aware of such really difficult cases as child-children, ox-oxen, brother-brethren, sheep-sheep and a few others. :)

Are your shrunken skulls reusable? ;D
Title: Re: Bytecode Interpreter concept
Post by: JRS on May 25, 2014, 02:10:56 PM
Touch screens sort of spoiled my plans of making mouses out of them.  :'(

Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 02:14:24 PM
Quote
And you'll have to wait a little more for an Oxygen version of Toy interpreter.
Oxygen memory allocation is still too buggy for that.

-oh this is not good news...even i think that i can force
Oxygen to do that...hey i even create toy interpreter with all
old bugs and work .

Mike i use in my editor this:

sRet = ShellExecute 0,"open","fbsl.exe",chr(34)+fName+chr(34),"",5

and as you can see ...it work like a charm

Mike you have in this include file (Events.inc)
3 CASE options..right?

1. ID_RUN - red button
which is suposed to run file and eventualy save before execution
using startup file...right?

2.IDM_RUNFILE - yellow button...who not respond?
which must run file
And in your version of ShellExecute you use NULL pointer instead of
proper command "open"...why you that i am not sure ?
Rest of function looks ok to me .

So i will modify this function and try to recompile...
i think that this NULL pointer is a main problem on my xpsp2.
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on May 25, 2014, 02:19:36 PM
I remember visiting the Pitt-River Museum, when I was at Oxford, and seeing their shrunken head exhibits in the flesh, so to speak. They were strangely both cute and macabre at the same time.

(http://www.oxfordtimes.co.uk/resources/images/561329.jpg?type=articlePortrait)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 02:39:32 PM
Aurel,

Your interpreter uses simple data type arrays while the Toy interpreter uses arrays of user-defined types that are apparently causing some memory corruption in the current version of Oxygen. I have however filed a corresponding report on the Bugs and Feature Requests board so that Charles can look into the matter and possibly fix it soon.

As for NULL in ShellExecute(), it stands for the default action of Fbsl.exe on the files whose .FBS extension is associated with this executable. We can try and change Eclecta's function to "open" too and see what happens.

P.S. Please try the attached Eclecta executable on your PC - it has "open" added instead of NULL.

.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 02:43:08 PM
Mike i get it finally and i t looks that i have a right .
I don't know how this work on someone else computer or OS version but on mine
this combination fly...

ok i do this:
Code: [Select]
CASE IDM_RUNFILE
IF FileOpened THEN
'==============================================
' Optionally save the script before execution
'==============================================
IF autosave THEN
IF SendMessage(hwndRichEdit, EM_GETMODIFY, 0, 0) THEN SaveFile()
END IF
SetCurrentDirectory(LEFT(FileName, INSTRREV(FileName, "\")))
ShellExecute(0,"open", "fbsl.exe",chr(34)& FileName & chr(34), "", SW_SHOWNORMAL)
ELSE
MSGBOX(ME, "No file to run!", "Execution Error", MB_OK BOR MB_ICONERROR)
SetFocus(hwndRichEdit)
END IF

So as you same way i do in my simple editor... :D
And work fine...
Of course i first copy all files from FULL_IDE folder to main FBSL folder then
from my editor run Eclecta from source...
open file toy.fbs
then click on 'yellow button' and voila finaly
interpreter is runing...  ;)

Well it is interesting ..i understand FBSL almost without learning or looking into help file.
Syntax is nice and clean and because i know very good part of win api functions
there is no problem for me to understand what is what.



.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 02:46:34 PM
Charles,

I lived and worked at the Ugandan/Congolese border for nearly 2 years at the end of 70's. The local pygmies used to trade their stuff including shrunken heads for haircombs, pencils, and pocket mirrors. But I never accepted them because I knew I wouldn't be able to get them through the customs at the Soviet border in Sheremetyevo airport in Moscow.

I traded many tom-toms and small hunting bows with arrows but they took away the arrows at the customs anyway - they said they might be poisoned with curare. :)
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 02:47:06 PM
Quote
Your interpreter uses simple data type arrays while the Toy interpreter uses arrays of user-defined types that are apparently causing some memory corruption in the current version of Oxygen. I have however filed a corresponding report on the Bugs and Feature Requests board so that Charles can look into the matter and possibly fix it soon.

thanks Mike
Yes you have right ,it looks to me when i first time try to convert toy interpreter that something
is wrong with this UDT array but maybe can be solved in a different way...
ok it is always best to wait for Charles what he can tell about that possible problem.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 02:49:35 PM
Quote
Please try the attached Eclecta executable on your PC - it has "open" added instead of NULL.

Ok i will,but i already do that myself ...you just post faster than me ... :-\
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 02:54:07 PM
All right Aurel,

I'm glad it finally worked for you either way, yours or mine. :)

I'd rather still not hardcode "fbsl.exe" into this function. You will have a choice through the Options dialog to specify either Fbsl.exe or Fbsl_Tiny.exe to run your scripts. That way you can be perfectly sure your creations will work equally well with the both implementations of FBSL - an executable and a DLL.
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 25, 2014, 02:57:45 PM
Hi Kuron,

It had been scheduled for mid-April before I was laid up with flu and also before that bloody horror started in Ukraine. The both dramatic developments spoiled my productivity and ruined my plans seriously and now I'm still catching up very slowly with my schedule. I have yet a large piece of FBSL BASIC manual to write and about a hundred samples to update.

At any rate, now I'm planning to have it all ready for publication by the end of July at the most. This is when I'm supposed to change my current place of residence for the city of Minsk again; this is when I'll be completely off the air for about 10 days or so.

I'm going back to my last harbor, gentlemen. :)

I am behind on stuff, too.  Between my fiancee battling breast cancer, our daughter having a brain tumor pressing on her pituitary gland, I took a nasty fall on some icy steps on Valentine's Day and ended up with a nasty concussion and also managed to injure my left hand.  The left hand being messed up made it really hard to get some contract work done.  Of course, I got another injury to the left hand two weeks ago which made it even worse.  It has been a hellish couple of months.

Anyway, my reason for asking is I wanted to set up a summer coding class for kids in my area.  Due to health issues, I have missed the deadline for that.  Now, I am aiming for an after school program when school starts back up in the fall.  Anytime I run this class, I try and use a different programming language.  It needs to be something free, and have an unrestricted license.  Unfortunately, 3.5 won't quite be out in time, so I think I will use MiniBasic as then I can cover 2D and 3D.  The last time I taught the class, I used QB64, but it had gotten a bit weird the last time I looked at it.

Anyway, I will definitely check out 3.5 for my own use when it is released. :c)  Good luck on your move.

 
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 02:59:18 PM
Yes i understand your point and i agree with you
BUT then you must chek again all this function and fix this somehow..
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 03:13:41 PM
Yes Aurel,

Thanks for co-operation. I will add it to the next release of Eclecta and I will especially acknowledge you in the History section of Eclecta's help file. What name will you prefer to go under: Aurel, AurelB, ruben, zlatkoAB or any else? :)
Title: Re: Bytecode Interpreter concept
Post by: JRS on May 25, 2014, 03:15:12 PM
Quote
It has been a hellish couple of months.

Stay strong and remember you don't have to be a hero. Be honest with yourself and your current limitations and ask others to step up and do their part. I'm still on a 5 year run turning my nightmare with my daughter's H1N1 battle and recovery around.



Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 25, 2014, 03:21:36 PM
Quote
Yes Aurel,

Thanks for co-operation. I will add it to the next release of Eclecta and I will especially acknowledge you in the History section of Eclecta's help file. What name will you prefer to go under: Aurel, AurelB, ruben, zlatkoAB or any else? :)

No problem Mike  ;)
This part of win programming is somehow my Area  and when i drop on
something ..this must work on one way or another...
of course some experience always help ..
Aurel is ok  :)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 03:23:42 PM
Brice,

You could have used FBSL v3.X XXX yesterday, a year, or a decade ago without any special permission. I said it was specifically meant for education, self-education, and fun from its very beginning. Go ahead with FBSL any time you feel like it. There is no need to contact anybody for any permission or license whatsoever and there never was. :)

Why didn't you start with that message in the first place? :)

P.S. What specific assistance do you need from me in your project? Don't hesitate to ask in case you need any.
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on May 25, 2014, 03:42:20 PM

Mike, I have fixed a problem with string members of  local UDT variables. This only occurred when no other string variable were present in the function. Also fixed another issue with returned bstrings.

http://www.oxygenbasic.org/o2zips/Oxygen.zip


We are all glad that you were able to return from the Congo with your own head securely attached to the rest of your person. :)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 25, 2014, 03:53:00 PM
Thanks Charles,

I'll try out the new zip tomorrow as it's quite late here already for any serious work, OK?

I was on the Ugandan side of the border actually. Those were the places that were depicted in your recent gorilla video on the thinBasic site. :) And why are you so sure my somewhat shrunken head isn't simply sewn back to my remaining poor self? :D Or, is this exactly what "securely attached" actually means? ;D


P.S. No Charles, this Oxygen.dll crashes for me exactly like the old one with that script I published on the Bugs board... :( See here, please (http://www.oxygenbasic.org/forum/index.php?topic=1097.msg9332#msg9332).
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 26, 2014, 05:08:46 AM
Ok back to topic....

I am looking into FBSL and FB version and found variable
command or command$
and oxygen say that is not defined and is true ..
so what a heck is this command   ???

FB version :
Code: [Select]
sub main()
    dim filename as string

    filename = command$
    if filename = "" then
        input "enter filename: ", filename
    end if
    if filename = "" then
        system
    end if
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 26, 2014, 05:17:08 AM
Another change:
Code: [Select]
sub init_lex(filename as string)
    src = GetFile(filename)      'open filename for input as #1
    cur_line_num = 0
is this correct ?
I use something like that in ASciEdit    .hmmm

then what about eof ?
I think that oxygen don't need eof..right?
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 26, 2014, 05:26:56 AM
then oxygen says:

Too many right brackets...  ???
in this subroutine:

Code: [Select]
sub get_string()
    dim start_line as integer
    sym = sym_string_const
    token = ""
    start_line = error_line
    next_char
    while cur_ch <> chr(34)
        if cur_ch = "" then
            sym = sym_eoi
            error_msg("eof found in string")
            exit while
        end if
        if error_line > start_line then
            error_msg("string must be on one line")
            exit while
        end if
        token = token + cur_ch
        next_char
    wend
    if cur_ch = chr(34) then
        next_char
    end if
end sub

so far in attachment :


.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 26, 2014, 05:45:23 AM
Hehe Aurel,

You're very far behind my own headaches with the Oxygen port of Toy interpreter. You're in fact only at the very beginning of the long and winding road. :)

Let's do it this way - I'll finish it when time and Charles permit, publish it, and then we can discuss everything in detail.

FB's Command$ and FBSL's Command(X) are means to obtain the application command-line parameters. The command-line parameter to toy.exe is the name of test file (primes.toy) which it must load. If it wasn't specified explicitly, then you're given a chance to type it in manually. Dragging-and-dropping primes.toy on toy.exe also makes use of this parameter implicitly BTW.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 26, 2014, 06:37:18 AM
Yeah Mike ..
maybe i am and maybe i'm not
Don't forget that i use oxygen more than you and i know when i can escpect
quirks....
from the other side you have far more experience in that stuff
and FBSL version work very well..
Title: Re: Bytecode Interpreter concept
Post by: Kuron on May 26, 2014, 01:49:42 PM
John:  Thank you, my friend.


Quote
You could have used FBSL v3.X XXX yesterday, a year, or a decade ago without any special permission. I said it was specifically meant for education, self-education, and fun from its very beginning. Go ahead with FBSL any time you feel like it. There is no need to contact anybody for any permission or license whatsoever and there never was. :)

Why didn't you start with that message in the first place? :)


Two different posts, two different things. ;c) 

The first post was about using FBSL for some contract work.  Technically, I quit taking contract work at the end of the year and from now on I am supposed to only be programming what I want to instead of what I am paid to do.  Any income was supposed to come from my music.  Unfortunately, with the injuries to my left hand, I can't play guitar very easily right now and trying to keep doing it is not letting the hand heal.

I am contemplating picking up some contract work if finances get tight.  I have moved all of my systems over to Linux, so this would mean setting up a Windows system and deciding on a programming language to use.  Unless I do some contract work, I no longer plan to release any Windows software.  Even if I was not doing contract work and was solely working on freeware, even if I put out some Windows stuff, the current license of FBSL would not work in my situation, since the freeware would be released by a company that still brings in revenue from other sources.

The second post was about use for a programming class I have taught off and on over the years, as a summer program and as an after school program.  The class is not free, there is a registration fee.  I am also not positive I am going to do it when school goes back in session.  Dealing with a lot of heavy stuff at  this time.  I might skip it again this year.  If I were to do it, using MiniBasic would make it much simpler as I already have the course material written.

Either way, I will be checking out FBSL 3.5 when it is released.  I should have Wine figured out by then. LOL
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 26, 2014, 11:19:30 PM
Thanks for clarifying your situation, Kuron!

While you're certainly not supposed to use FBSL under the circumstances as per paragraph 2 without a license, you could have, and still can, use FBSL freely for the purposes of paragraph 3 even if you're going to be paid for your educational work. Public benefit of your educational activities clearly and definitively outweighs all other considerations, and cash refund of a teacher for his work has nothing to do with the "commercial activity" concept. (I'm an English and French school teacher myself by two of my numerous certified specialities, and was also a long time bass guitar player in a semi-professional hard rock band back in 70's/80's.)

Get well soon and thanks again for your interest in FBSL! :)
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 28, 2014, 11:18:59 AM
Again back to topic...

i have strange problem with this function which looks to me
very unlogical, this function have two arguments...
and as return tend to use one argument what is wrong...

Code: [Select]
' see if an ident exists in the symbol table - boolean return
function is_in_sym_tab(ident as string, address as long) as long
    dim i as int

    i = find_sym_tab(ident)
    if i = 0 then
        'is_in_sym_tab = false
        exit function
    end if

    address = sym_tab[i].data_index
    is_in_sym_tab = true

end function
Title: Re: Bytecode Interpreter concept
Post by: Ed Davis on May 28, 2014, 12:17:55 PM
Its a bug.  address should be "byref".

The goal is to determine if a symbol has already been defined, and if it has, return its address.

It is corrected in Mike Lobanovsky FBSL version.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on May 28, 2014, 12:29:45 PM
@Ed:

Hard to tell if it is or it isn't. If what he has here comes from FB -lang qb or from FBSL then ByRef is the language default when not specified explicitly. So address will change its value in the caller code alright either way.

P.S. ByRef is used in my FBSL port deliberately only to stress what I've said above. Otherwise it may be omitted to the same effect.

@Aurel:

Whenever you publish a question, can you please specify exactly what code we're seeing in your example: FB, FBSL, Oxygen, or some intermediate stage of you porting efforts?

Thank you.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on May 28, 2014, 01:24:01 PM
Thanks Ed i will look into Mike- FBSL version.  ;)

Mike
Yes it is translation to Oxygen ..so code is in Oxygen Basic.
It is very messy right now but i hope that i will fix few quirks.  ::)
Good thing is that we have your FBSL version which looks that work as
is suposed to be .
Title: Re: Bytecode Interpreter concept
Post by: Kuron on June 08, 2014, 11:22:16 AM
While you're certainly not supposed to use FBSL under the circumstances as per paragraph 2 without a license, you could have, and still can, use FBSL freely for the purposes of paragraph 3 even if you're going to be paid for your educational work. Public benefit of your educational activities clearly and definitively outweighs all other considerations, and cash refund of a teacher for his work has nothing to do with the "commercial activity" concept. (I'm an English and French school teacher myself by two of my numerous certified specialities, and was also a long time bass guitar player in a semi-professional hard rock band back in 70's/80's.)

Get well soon and thanks again for your interest in FBSL! :)
To be clear, I don't get paid for my teaching.  It is strictly volunteer work.  The fees are charged by the center and go for covering insurance and other expenses for the kids. :)

On the bright side, they re building a new community center, so eventually, the programming class will be back.

Bass, huh?  I play bass too (among several other instruments).

Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on June 08, 2014, 12:23:30 PM
On the bright side, they re building a new community center, so eventually, the programming class will be back.
Excellent! :)

Quote
Bass, huh?  I play bass too (among several other instruments).
Unfortunately I can't do that any more due to visible contractures in my ring and little fingers but my black Gibson Les Paul Bass still stands in its case deep in my wardrobe, and my four Peavey Bandits, in my garage. :)
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on July 23, 2014, 08:31:46 AM
Hello everybody,

I didn't want to push Charles unnecessarily so it did take O2 some time to sort out its memory problems. I'm glad to announce that Oxygen is now fit to compile and run Ed Davis' Toy interpreter correctly. Attached you will find a precompiled executable as well as toy.o2bas and primes.toy scripts to match.

The O2 version looks and works exactly like its earlier FBSL counterpart barring minor differences in Select Case handling and an O2 Do/Loop block that substitutes the original FBSL While/WEnd that still causes severe memory corruption in O2. You can find it commented out in Sub get_ident().

Wows and awesomes appreciated but not absolutely necessary. :D



.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on July 23, 2014, 11:44:47 AM
what to say ...fine  ;)
well i can't say that for my version because i want create version without console.
Quote
While/WEnd that still causes severe memory corruption in O2
hmm that maybe a part of problem with my version but i am not sure because i have
to much errors or I mess up something ...

all in all.... thanks Mike  ;)
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on July 23, 2014, 11:49:05 PM
Many thanks Mike.

I checked the troublesome 'while' loop. The assembly code appears to be okay at first glance, but I will investigate further.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on July 24, 2014, 12:12:03 AM
Hi Charles,

The triple OR conditional with two direct function calls in it doesn't work for me here in either a While or an If statement. :-\

All other While/WEnd and If/Then blocks throughout the script are simpler in this regard.
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on July 24, 2014, 12:49:30 AM
The problem is with a string comparison in a compound statement. All other aspects look ok.

Code: [Select]
#show while is_alpha() or is_numeric() 'or cur_ch+" " = "_"
token = token & cur_ch
next_char()
wend
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on July 24, 2014, 11:21:00 AM
Oh, I see.

Then

Code: [Select]
byte c = asc(cur_ch)

while is_alpha() or is_numeric() or c = 95 ' asc("_")
token = token & cur_ch
next_char()
wend

might cure the situation in situ. But that'll be only a palliation, sort of yet another "crutch", don't you think?
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on July 24, 2014, 11:04:29 PM
Yes I am working on the remedy. The problem appears to be a rogue optimization.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on July 25, 2014, 04:53:32 AM
Thanks, Charles.
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on July 25, 2014, 02:35:46 PM

Update with repaired compound conditional string comparisons:

http://www.oxygenbasic.org/o2zips/Oxygen.zip

This should not leak, since no temp strings are generated in the while clause:

Code: [Select]
sub get_ident()
token = ""
while is_alpha() or is_numeric() or cur_ch = "_"
token = token & cur_ch
next_char()
wend
    sym = search_key_words()
end sub

Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on July 25, 2014, 06:48:06 PM
Oh Charles,

Thanks a lot for fixing the problems so quickly. You're indeed very responsive to the needs of language users and extremely productive at that too. :)
Title: Re: Bytecode Interpreter concept
Post by: Charles Pegge on July 25, 2014, 10:40:23 PM
Thanks Mike,

One minor correction to prevent a GPF in JIT mode:


sub press_a_key()
    print cr "Press any key to continue..."
    waitkey
    end
end sub

end is not normally required, but should be placed outside any procedures, in the main body of the program.
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on July 26, 2014, 03:47:26 AM
Thanks for the tip, Charles.

Then I'd put it in the global code immediately following the call to main().
Title: Re: Bytecode Interpreter concept
Post by: Aurel on September 04, 2014, 06:26:52 AM
For Mike

What could be the simpliest method for my interpreter that can intecept windows messages
properly and without any interference ?
Why i ask..hmm i think that old method i use is little bit clumsy
thanks !
Title: Re: Bytecode Interpreter concept
Post by: Mike Lobanovsky on September 04, 2014, 08:38:13 AM
Hi Aurel,

Your WndProc() is the only place where you're supposed to process messages that are coming to the two main windows of your application. The same callback can also be used for any additional windows that you might add in the future as long as these windows are not of any special type e.g. control or dialog windows. And yes, you can differentiate between the windows by their handles like you do. From this standpoint, your design is absolutely correct.

I'd only suggest you observe the following simple rules when working with messages in this callback:

Firstly, almost every message is supposed to return a special value from this callback to the system. Presently all your messages fall through to the common Return DefWindowProc hwnd, wMsg, wParam, lParam command. This means that whatever you do in your message handlers, the system will also add its default processing after all your actions. If you look attentively into the MSDN, you will see that each window message entry there has the following hint:

Return Values

An application should return N if it processes this message.


where N is a numeric value that the callback should return to avoid default processing. Most of the messages should return 0 or 1, for example

Case WM_PAINT
    BitBlt hdc, 0, 0, width, height, hmemdc, 0, 0, SRCCOPY
    Return 0

This will prevent falling through to Return DefWindowProc(). A few messages however need to return other values. The MSDN is your best friend when working with the Windows message pipe.

Secondly, some of your actions don't need immediate response from the system and shouldn't break its default behavior. In this case, you shouldn't use SendMessage() in the callback when processing other messages. Use PostMessage() instead and let the current message fall through to DefWindowProc(), i.e. don't use any special Return for it.

The difference between SendMessages() and PostMessage() is that the former blocks the callback until the SendMessage() call is executed in full while the latter proceeds immediately not blocking it. The message you've just posted will be placed in the window message queue and executed in a natural non-blocking manner at some later time.

Here too, you should consult the MSDN to see if the message in question is normally sent or posted. Each message entry there will usually start with something like

An application sends the WM_PAINT message when ...

or

The WM_KEYDOWN message is posted to the window ...

There are only slight differences in how Windows would process sent and posted messages but in very many cases the effect of this difference is exactly what you're after in your code.
Title: Re: Bytecode Interpreter concept
Post by: Aurel on September 04, 2014, 12:53:06 PM
Thank you Mike on very clear explanation  ;)
ok i will check all options.
Title: Re: Bytecode Interpreter concept
Post by: Frankolinox on September 05, 2014, 02:20:31 AM
aurel, specify your problem with an example or code snippet, perhaps I can help too.

for programming and learning resources check also "petzold" win api examples for further studies, that's really a treasure ;)

regards, frank
Title: Re: Bytecode Interpreter concept
Post by: Aurel on September 05, 2014, 10:12:35 AM
Hi Frank
I will post this question on my forum and i always want your experience
if i remember i ask you few times some things..
 :)