Thread: RE: [VB4Linux-Dev] hey I guess so.
Status: Planning
Brought to you by:
luke-jr
Menu
▾
▴
vb4linux-dev
|
From: Scott B. <js...@go...> - 2000-11-19 15:41:32
|
>how do we divide the work? >FROM: Abhijit PaithankarDATE: 11/17/2000 >I think instead of giving 2 options, we could have just a VB2C >interpreter. Anyone looked at this: http://www.naken.cc/vb2c/ >CHM Reader/Viewer and CHM Compiler >Syntax colorer and GUI i.e. GUI and the editor >VB2C interpreter and Syntax checker What about holding off until a base vb2c is done, then code most of the tools in the language itself, or do them in VB now and use them as a test for the translator? >other tasks like runtime debugger need to be thought of coz` of >interpreting, the debugger shall need to reverse-interpret the C code to >VB Same as above. >at design-time, we can emulate the Win32 API. should we make use of Wine >where? >that shall take care of OCX stuff. I would use the Wine libs.... saves time and money ;-) scott |
|
From: Abhijit P. <abh...@ma...> - 2000-11-19 16:54:54
|
> -----Original Message----- > From: vb4...@li... > [mailto:vb4...@li...]On Behalf Of Scott > Beasley > Sent: Sunday, November 19, 2000 7:28 AM > To: vb4...@li... > Subject: RE: [VB4Linux-Dev] hey I guess so. > > > >how do we divide the work? > >FROM: Abhijit PaithankarDATE: 11/17/2000 > > >I think instead of giving 2 options, we could have just a VB2C > >interpreter. > Anyone looked at this: http://www.naken.cc/vb2c/ It looks OK, but we shall have to request him for the source code...atleast the basic stuff is already present.... > >CHM Reader/Viewer and CHM Compiler > >Syntax colorer and GUI i.e. GUI and the editor > >VB2C interpreter and Syntax checker > What about holding off until a base vb2c is done, then code most of the > tools in the language itself, or do them in VB now and use them as a test > for the translator? Since a lot of work is to be done on the GUI/Editor, like being able to create a project and work within the project, the toolbars are to be emulated, and a lot of other stuff needs to be figured out, the GUI/Editor can be developed independently and then the projectfile shall be passed on to the VB2C compiler....actually, you could download the vb2c interpreter at the URL above, and start off on that. > >other tasks like runtime debugger need to be thought of coz` of > >interpreting, the debugger shall need to reverse-interpret the C code to > >VB > Same as above. ya....this needs some ground work to be done before starting off > >at design-time, we can emulate the Win32 API. should we make use of Wine > >where? > >that shall take care of OCX stuff. > I would use the Wine libs.... saves time and money ;-) Pls check if Wine can emulate the OCX controls...and how do we integrate them in the code that is to be converted to C...I am still not sure about this stuff... ab |
|
From: Luke-Jr <Mi...@an...> - 2000-11-19 18:48:17
Attachments:
Mike.vcf
|
Erm... Fix your clock please? It's not the 20th and if you're in a different timezone, shouldn't it put the -0500 or something in the Date header... Replies inside message below: Abhijit Paithankar wrote: > > -----Original Message----- > > From: vb4...@li... > > [mailto:vb4...@li...]On Behalf Of Scott > > Beasley > > Sent: Sunday, November 19, 2000 7:28 AM > > To: vb4...@li... > > Subject: RE: [VB4Linux-Dev] hey I guess so. > > > > > > >how do we divide the work? > > >FROM: Abhijit PaithankarDATE: 11/17/2000 > > > > >I think instead of giving 2 options, we could have just a VB2C > > >interpreter. > > Anyone looked at this: http://www.naken.cc/vb2c/ > > It looks OK, but we shall have to request him for the source code...atleast > the basic stuff is already present.... Yup... > > > > >CHM Reader/Viewer and CHM Compiler > > >Syntax colorer and GUI i.e. GUI and the editor > > >VB2C interpreter and Syntax checker > > What about holding off until a base vb2c is done, then code most of the > > tools in the language itself, or do them in VB now and use them as a test > > for the translator? > > Since a lot of work is to be done on the GUI/Editor, like being able to > create a project and work within the project, the toolbars are to be > emulated, and a lot of other stuff needs to be figured out, the GUI/Editor > can be developed independently and then the projectfile shall be passed on > to the VB2C compiler....actually, you could download the vb2c interpreter at > the URL above, and start off on that. Hmm... In that case, I could start on the GUI today... I'm MUCH better at VB than C... (I'll just have to remember not to use the WinAPI as I doubt VB2C will make up for that for a while...) > > > > >other tasks like runtime debugger need to be thought of coz` of > > >interpreting, the debugger shall need to reverse-interpret the C code to > > >VB > > Same as above. > > ya....this needs some ground work to be done before starting off > > > >at design-time, we can emulate the Win32 API. should we make use of Wine > > >where? > > >that shall take care of OCX stuff. > > I would use the Wine libs.... saves time and money ;-) > > Pls check if Wine can emulate the OCX controls...and how do we integrate > them in the code that is to be converted to C...I am still not sure about > this stuff... Wine can emulate OCX controls... There's 2 possibilities for including Windows files: 1. Link a modified version of Wine in with the program and emulate the OCXes only (if possible) 2. Pre-emulate the OCX controls into C code and link a "ported" OCX into the program... > > > ab > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev |
|
From: Abhijit P. <abh...@ma...> - 2000-11-19 19:34:46
|
pls see message below: > Erm... Fix your clock please? It's not the 20th and if you're in > a different > timezone, shouldn't it put the -0500 or something in the Date > header... Done sir! :) > > > >I think instead of giving 2 options, we could have just a VB2C > > > >interpreter. > > > Anyone looked at this: http://www.naken.cc/vb2c/ > > > > It looks OK, but we shall have to request him for the source > code...atleast > > the basic stuff is already present.... > > Yup... > > > Since a lot of work is to be done on the GUI/Editor, like being able to > > create a project and work within the project, the toolbars are to be > > emulated, and a lot of other stuff needs to be figured out, the > GUI/Editor > > can be developed independently and then the projectfile shall > be passed on > > to the VB2C compiler....actually, you could download the vb2c > interpreter at > > the URL above, and start off on that. > > Hmm... In that case, I could start on the GUI today... I'm MUCH better at > VB than C... > (I'll just have to remember not to use the WinAPI as I doubt VB2C > will make up > for that for a while...) yes...the earlier the better. also, we could use the latest version of GTK+...just make sure all of use the same versions of any libraries/software we use. For the GUI, I think you should program directly in C on the Linux box. I am really doubtful of how powerful vb2c is at present....would it be able to interpret all those toolbars, and "File Open" dialog boxes and all that? > > Pls check if Wine can emulate the OCX controls...and how do we integrate > > them in the code that is to be converted to C...I am still not > sure about > > this stuff... > > Wine can emulate OCX controls... There's 2 possibilities for > including Windows > files: > 1. Link a modified version of Wine in with the program and emulate the > OCXes only (if possible) > 2. Pre-emulate the OCX controls into C code and link a > "ported" OCX into > the program... Some team members could do some R&D on this topic. It would be of great help. ab |
|
From: Luke-Jr <Mi...@an...> - 2000-11-19 19:49:29
Attachments:
Mike.vcf
|
Abhijit Paithankar wrote: > pls see message below: > > > Erm... Fix your clock please? It's not the 20th and if you're in > > a different > > timezone, shouldn't it put the -0500 or something in the Date > > header... > > Done sir! :) > > > > > >I think instead of giving 2 options, we could have just a VB2C > > > > >interpreter. > > > > Anyone looked at this: http://www.naken.cc/vb2c/ > > > > > > It looks OK, but we shall have to request him for the source > > code...atleast > > > the basic stuff is already present.... > > > > Yup... > > > > > Since a lot of work is to be done on the GUI/Editor, like being able to > > > create a project and work within the project, the toolbars are to be > > > emulated, and a lot of other stuff needs to be figured out, the > > GUI/Editor > > > can be developed independently and then the projectfile shall > > be passed on > > > to the VB2C compiler....actually, you could download the vb2c > > interpreter at > > > the URL above, and start off on that. > > > > Hmm... In that case, I could start on the GUI today... I'm MUCH better at > > VB than C... > > (I'll just have to remember not to use the WinAPI as I doubt VB2C > > will make up > > for that for a while...) > > yes...the earlier the better. > also, we could use the latest version of GTK+...just make sure all of use > the same versions of any libraries/software we use. > > For the GUI, I think you should program directly in C on the Linux box. I am > really doubtful of how powerful vb2c is at present....would it be able to > interpret all those toolbars, and "File Open" dialog boxes and all that? Well, nobody said that the GUI had to be compiled until the VB2C part of the project was done anyway... Besides, a complicated test program would probably be a necessity when working on the VB2C... > > > > > Pls check if Wine can emulate the OCX controls...and how do we integrate > > > them in the code that is to be converted to C...I am still not > > sure about > > > this stuff... > > > > Wine can emulate OCX controls... There's 2 possibilities for > > including Windows > > files: > > 1. Link a modified version of Wine in with the program and emulate the > > OCXes only (if possible) > > 2. Pre-emulate the OCX controls into C code and link a > > "ported" OCX into > > the program... > > Some team members could do some R&D on this topic. It would be of great > help. R&D?? > > > ab > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev |
|
From: Scott B. <js...@go...> - 2000-11-19 23:13:37
|
On Sun, 19 Nov 2000, Luke-Jr wrote: > Abhijit Paithankar wrote: > > > pls see message below: > > > > > Erm... Fix your clock please? It's not the 20th and if you're in > > > a different > > > timezone, shouldn't it put the -0500 or something in the Date > > > header... > > > > Done sir! :) > > > > > > > >I think instead of giving 2 options, we could have just a VB2C > > > > > >interpreter. > > > > > Anyone looked at this: http://www.naken.cc/vb2c/ > > > > > > > > It looks OK, but we shall have to request him for the source > > > code...atleast > > > > the basic stuff is already present.... > > > > > > Yup... > > > > > > > Since a lot of work is to be done on the GUI/Editor, like being able to > > > > create a project and work within the project, the toolbars are to be > > > > emulated, and a lot of other stuff needs to be figured out, the > > > GUI/Editor > > > > can be developed independently and then the projectfile shall > > > be passed on > > > > to the VB2C compiler....actually, you could download the vb2c > > > interpreter at > > > > the URL above, and start off on that. > > > > > > Hmm... In that case, I could start on the GUI today... I'm MUCH better at > > > VB than C... > > > (I'll just have to remember not to use the WinAPI as I doubt VB2C > > > will make up > > > for that for a while...) > > > > yes...the earlier the better. > > also, we could use the latest version of GTK+...just make sure all of use > > the same versions of any libraries/software we use. > > > > For the GUI, I think you should program directly in C on the Linux box. I am > > really doubtful of how powerful vb2c is at present....would it be able to > > interpret all those toolbars, and "File Open" dialog boxes and all that? > > Well, nobody said that the GUI had to be compiled until the VB2C part of the > project was done anyway... Besides, a complicated test program would probably > be a necessity when working on the VB2C... > I think it best to keep this part of the code as hi-level as possible. And again it does not matter if it is not compiled or compilable for awhile, without a good solid core (vb2c) it's useless anyway. The debugger is upfor debate on if it should be in C or VB. Though in the Tcl/Tk and Python world their debuggers are mixed. scott |
|
From: Scott B. <js...@go...> - 2000-11-20 00:14:45
|
Lets go over some issues and options we have in writing vb2c.
1 - The main translator does not have to be in C. (I vote C tho :-)
We could write the translator in something like Tcl or Python. This
would be for VB->C code generation only. The support libraries would
still be in C, and would be brought in during link time. Doing this
would simplify much of the parsing of the vb files, and would be
relatively fast.
2 - vb2c will have to be a multi-pass compiler or use very complicated
Look ahead logic. (I vote multi-pass)
We will need at least 3 passes to generate the code or a foo-bar FSM
(Finite state machine). You could/can generate most of the form info
(Window info) on the first pass, as most of that is close to a one to
one relation (i.e. Windows created -> Windows create code in C) But
branching, looping and such needs more info before you can generate
the target code. If & Select blocks also can change the flow of code,
so they need extra attention (more on these later also).
3 - A Type marshalling engine will be needed.
To keep things simple, we should have functions written to help out
with type converting (obvious) and things like If and Selects. C has a
much more limited type comparison set. Such as switch/case. In C this
is integer based (which is fine) but in VB select is not. We will
have to a set of functions or an engine to handle this.
4 - Others?
just a few things to think about.
scott
|
|
From: Luke-Jr <Mi...@an...> - 2000-11-20 04:47:02
Attachments:
Mike.vcf
|
Scott Beasley wrote: > Lets go over some issues and options we have in writing vb2c. > > 1 - The main translator does not have to be in C. (I vote C tho :-) > We could write the translator in something like Tcl or Python. This > would be for VB->C code generation only. The support libraries would > still be in C, and would be brought in during link time. Doing this > would simplify much of the parsing of the vb files, and would be > relatively fast. Tcl seems to be X11-only... The VB2C shouldn't require X11 as it isn't a GUI app... > > > 2 - vb2c will have to be a multi-pass compiler or use very complicated > Look ahead logic. (I vote multi-pass) > We will need at least 3 passes to generate the code or a foo-bar FSM > (Finite state machine). You could/can generate most of the form info > (Window info) on the first pass, as most of that is close to a one to > one relation (i.e. Windows created -> Windows create code in C) But > branching, looping and such needs more info before you can generate > the target code. If & Select blocks also can change the flow of code, > so they need extra attention (more on these later also). I know this may sound stupid, but why must it be multi-pass? Maybe if it's not Option Explicit then there might be a reason to need that, but even still for non-OE programs there could be one "default" type which could be a wildcard... > > > 3 - A Type marshalling engine will be needed. > To keep things simple, we should have functions written to help out > with type converting (obvious) and things like If and Selects. C has a > much more limited type comparison set. Such as switch/case. In C this > is integer based (which is fine) but in VB select is not. We will > have to a set of functions or an engine to handle this. Well, I'd say making the "Select Case abc" become "select(MakeSelectInt(abc))" and have MakeSelectInt do an interger "encode" on the value and have maybe the first byte be representing the original type or something like that... > > > 4 - Others? > > just a few things to think about. > > scott > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev |
|
From: Scott B. <js...@go...> - 2000-11-20 13:27:43
|
On Sun, 19 Nov 2000, Luke-Jr wrote: > Scott Beasley wrote: > > > Lets go over some issues and options we have in writing vb2c. > > > > 1 - The main translator does not have to be in C. (I vote C tho :-) > > We could write the translator in something like Tcl or Python. This > > would be for VB->C code generation only. The support libraries would > > still be in C, and would be brought in during link time. Doing this > > would simplify much of the parsing of the vb files, and would be > > relatively fast. > > Tcl seems to be X11-only... The VB2C shouldn't require X11 as it isn't a > GUI app... Tcl is not Tk in this case (Tcl is the scripting language and Tk is the windowing Tool Kit) Tcl, Tk and Python are quite portable though, as portable as perl even. > > > > > > > 2 - vb2c will have to be a multi-pass compiler or use very complicated > > Look ahead logic. (I vote multi-pass) > > We will need at least 3 passes to generate the code or a foo-bar FSM > > (Finite state machine). You could/can generate most of the form info > > (Window info) on the first pass, as most of that is close to a one to > > one relation (i.e. Windows created -> Windows create code in C) But > > branching, looping and such needs more info before you can generate > > the target code. If & Select blocks also can change the flow of code, > > so they need extra attention (more on these later also). > > I know this may sound stupid, but why must it be multi-pass? Maybe if it's not > Option Explicit then there might be a reason to need that, but even still for > non-OE programs there could be one "default" type which could be a wildcard... Not stupid :-) This is just part of writing a compiler or language translator. For a translator you could do it single pass, but you could generate better code (and less) with a multi-pass system and also do some optimization on the last pass. > > > > > > > 3 - A Type marshalling engine will be needed. > > To keep things simple, we should have functions written to help out > > with type converting (obvious) and things like If and Selects. C has a > > much more limited type comparison set. Such as switch/case. In C this > > is integer based (which is fine) but in VB select is not. We will > > have to a set of functions or an engine to handle this. > > Well, I'd say making the "Select Case abc" become "select(MakeSelectInt(abc))" > and have MakeSelectInt do an interger "encode" on the value and have maybe the > first byte be representing the original type or something like that... > > > > > > > 4 - Others? > > > > just a few things to think about. > > > > scott > > > > _______________________________________________ > > VB4Linux-Dev mailing list > > VB4...@li... > > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev > |
|
From: Luke-Jr <Mi...@an...> - 2000-11-20 00:49:35
Attachments:
Mike.vcf
|
As this project is meant to be a near-exact port of Visual Basic (besides the binary result and OS), the debugger should be VB..... Scott Beasley wrote: > On Sun, 19 Nov 2000, Luke-Jr wrote: > > > Abhijit Paithankar wrote: > > > > > pls see message below: > > > > > > > Erm... Fix your clock please? It's not the 20th and if you're in > > > > a different > > > > timezone, shouldn't it put the -0500 or something in the Date > > > > header... > > > > > > Done sir! :) > > > > > > > > > >I think instead of giving 2 options, we could have just a VB2C > > > > > > >interpreter. > > > > > > Anyone looked at this: http://www.naken.cc/vb2c/ > > > > > > > > > > It looks OK, but we shall have to request him for the source > > > > code...atleast > > > > > the basic stuff is already present.... > > > > > > > > Yup... > > > > > > > > > Since a lot of work is to be done on the GUI/Editor, like being able to > > > > > create a project and work within the project, the toolbars are to be > > > > > emulated, and a lot of other stuff needs to be figured out, the > > > > GUI/Editor > > > > > can be developed independently and then the projectfile shall > > > > be passed on > > > > > to the VB2C compiler....actually, you could download the vb2c > > > > interpreter at > > > > > the URL above, and start off on that. > > > > > > > > Hmm... In that case, I could start on the GUI today... I'm MUCH better at > > > > VB than C... > > > > (I'll just have to remember not to use the WinAPI as I doubt VB2C > > > > will make up > > > > for that for a while...) > > > > > > yes...the earlier the better. > > > also, we could use the latest version of GTK+...just make sure all of use > > > the same versions of any libraries/software we use. > > > > > > For the GUI, I think you should program directly in C on the Linux box. I am > > > really doubtful of how powerful vb2c is at present....would it be able to > > > interpret all those toolbars, and "File Open" dialog boxes and all that? > > > > Well, nobody said that the GUI had to be compiled until the VB2C part of the > > project was done anyway... Besides, a complicated test program would probably > > be a necessity when working on the VB2C... > > > I think it best to keep this part of the code as hi-level as > possible. And again it does not matter if it is not compiled or > compilable for awhile, without a good solid core (vb2c) it's useless > anyway. The debugger is upfor debate on if it should be in C or > VB. Though in the Tcl/Tk and Python world their debuggers are mixed. > > scott > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev |
|
From: Abhijit P. <abh...@ma...> - 2000-11-20 08:08:55
|
The debugger should be in VB. This also means, we should be able to reverse interpret the C code. another way would be to parse the VB code itself and make sure there are (if possible) no erors (syntax or logical)in the code even before putting it thro vb2c. > > As this project is meant to be a near-exact port of Visual Basic > (besides the > binary result and OS), the debugger should be VB..... > > > I think it best to keep this part of the code as hi-level as > > possible. And again it does not matter if it is not compiled or > > compilable for awhile, without a good solid core (vb2c) it's useless > > anyway. The debugger is upfor debate on if it should be in C or > > VB. Though in the Tcl/Tk and Python world their debuggers are mixed. |
|
From: Scott B. <js...@go...> - 2000-11-20 13:32:00
|
On Mon, 20 Nov 2000, Abhijit Paithankar wrote: > The debugger should be in VB. > This also means, we should be able to reverse interpret the C code. > > another way would be to parse the VB code itself and make sure there are (if > possible) no erors (syntax or logical)in the code even before putting it > thro vb2c. We should beable to add debugging functions on the C side with no problem, again like Python and Tcl have. (always look to the past to see the future) > > > > > As this project is meant to be a near-exact port of Visual Basic > > (besides the > > binary result and OS), the debugger should be VB..... > > > > > I think it best to keep this part of the code as hi-level as > > > possible. And again it does not matter if it is not compiled or > > > compilable for awhile, without a good solid core (vb2c) it's useless > > > anyway. The debugger is upfor debate on if it should be in C or > > > VB. Though in the Tcl/Tk and Python world their debuggers are mixed. > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev > > |
|
From: Abhijit P. <abh...@ma...> - 2000-11-20 03:38:30
|
> > For the GUI, I think you should program directly in C on the > Linux box. I am > > really doubtful of how powerful vb2c is at present....would it > be able to > > interpret all those toolbars, and "File Open" dialog boxes and all that? > > Well, nobody said that the GUI had to be compiled until the VB2C > part of the > project was done anyway... Besides, a complicated test program > would probably be a necessity when working on the VB2C... I see your point.. but then you shall have to wait for a while before the vb2c is strong enough for it. again, the programs that have been compiled with vb2c might not be as optimized/fast as their C counterparts > > > > Pls check if Wine can emulate the OCX controls...and how do > we integrate > > > > them in the code that is to be converted to C...I am still not > > > sure about > > > > this stuff... > > > > > > Wine can emulate OCX controls... There's 2 possibilities for > > > including Windows > > > files: > > > 1. Link a modified version of Wine in with the program > and emulate the > > > OCXes only (if possible) > > > 2. Pre-emulate the OCX controls into C code and link a > > > "ported" OCX into > > > the program... > > > > Some team members could do some R&D on this topic. It would be of great > > help. > > R&D?? Research & Development finding, trying and testing |
|
From: Luke-Jr <Mi...@an...> - 2000-11-20 04:50:02
Attachments:
Mike.vcf
|
Not at first, but I hope with time that we'll be able to work in optimization generators for the conversion... After all, VB for Windows does some internal program conversion and optimization itself (no, VB5+ don't go straight to binary, they convert it to some other ((maybe unknown)) language and optimizes it... How else could there be "Optimize for Size" and "Optimize for Speed"?)... Abhijit Paithankar wrote: > > > For the GUI, I think you should program directly in C on the > > Linux box. I am > > > really doubtful of how powerful vb2c is at present....would it > > be able to > > > interpret all those toolbars, and "File Open" dialog boxes and all that? > > > > Well, nobody said that the GUI had to be compiled until the VB2C > > part of the > > project was done anyway... Besides, a complicated test program > > would probably be a necessity when working on the VB2C... > > I see your point.. > but then you shall have to wait for a while before the vb2c is strong enough > for it. > > again, the programs that have been compiled with vb2c might not be as > optimized/fast as their C counterparts > > > > > > Pls check if Wine can emulate the OCX controls...and how do > > we integrate > > > > > them in the code that is to be converted to C...I am still not > > > > sure about > > > > > this stuff... > > > > > > > > Wine can emulate OCX controls... There's 2 possibilities for > > > > including Windows > > > > files: > > > > 1. Link a modified version of Wine in with the program > > and emulate the > > > > OCXes only (if possible) > > > > 2. Pre-emulate the OCX controls into C code and link a > > > > "ported" OCX into > > > > the program... > > > > > > Some team members could do some R&D on this topic. It would be of great > > > help. > > > > R&D?? > > Research & Development > finding, trying and testing > > _______________________________________________ > VB4Linux-Dev mailing list > VB4...@li... > http://lists.sourceforge.net/mailman/listinfo/vb4linux-dev |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X