[Gambas-user] Gambas Future or what kind of Gambas we want.

[Carl Nilsson]

The Future and what kind of Gambas do we 
want?  Well, this is a question general enough 
that I can understand it and put in my modest contribution:
I have just started using Gambas.  A year ago I 
started asking a question or two on this forum 
about using it to write for an embedded system on 
small aircraft.  It is the application I wish to 
concentrate my limited time on, not Gambas and 
certainly not Linux, both of which I wanted to 
use. My questions were pretty naive and simple, 
like how to set up and use multiple serial ports 
for a processing system.  I was previously and 
still am using a Windows 2000 lite sytem with 
software I have written in VB6, about which I 
know enough to get by.  I also know enough about 
Windows to know it was not ideal.  My system is 
not commercial (though I thought it might become 
one 10 years ago).  But I was not going to pay for Windows Embedded.

In the meantime along come boards like the 
Raspberry Pi and the Beaglebone Black.  Raspberry 
Pi has about 2 million boards sold.  That's where 
the future lies for Gambas - not with computer 
experts on desktops, but with people who want to 
use cheap systems largely for educational and 
hobby projects.  People like myself who were 
prepared to dig into VB6, but not go with 
successive versions of VB.net and Embedded Windows.

Yesterday, working on Gambas 3.5.1 running on 
OpenSUSE 13.1 running on VM under Windows 7, I 
finally got as far as writing a small program 
that actually received data over a serial 
port.  I was almost there several days ago - 
thanks to the Gambas examples and helpful input 
from this forum.  However, I got held up , as an 
ordinary (non-root) user, by not being able to 
open the serial port!  A trivial matter, you 
might think, but I had to dig into Linux to join 
the network group that had permission to access 
the serial port!   For me, Linux is simply there 
as the carrier of Gambas and I do not have the 
time in which to become a happy chappie forever playing with Linux.

I note there is GambOS.  I have not yet looked at 
it, but I get the intent.  For home automation, 
it seems the right idea.  I have little doubt 
that boards like Raspberry Pi and Beaglebone, and 
tablets and smart phones  will dominate the 
market in future.  Right now, Gambas and Linux go 
together.  But if you want a much greater takeup 
of Gambas, you must make the installation and use 
of an O/S with Gambas easier and more 
transparent.  Look at the hardware and users it 
is likely needed for.   Here's an image, burn it 
on an SD card and away you go.  Right now I would 
love to be able to download a current 
installation image for the Raspberry Pi that had 
Gambas and Wiring Pi integrated.  Similarly for 
the Beaglebone Black.  So that the user can get 
right down to programming his device using a 
custom version of Gambas that suits the 
hardware.  I should not have to purchase a small 
library of books on Linux.  I would advocate more 
effort towards the non-expert user who wants to 
use popular and inexpensive hardware.

That's my take.
Carl




At 07:57 AM 22/01/2014, you wrote:
>Stepping in this old conversation to point out my take:
>
>-computers nowadays are fast enough to run a VM that's fast enough to
>run a normal aplication
>
>-If Benoit says it's complicated, what's left for us ??????????????????
>
>- so instead of trying to port gambas, why not making a installer that
>sets everything up for the inexperinced user??? Something like the
>SmallTalk approach.
>
>Making a small footprint VM+Linux+Gambas...they're all opensource, we
>can get rid of everyhing that Gambas dont need...even more, making a
>ligth weight Gambas or tagging components as "portable" and others "not"
>Say it's a 500MB installer? C'mon my android phone has "Hello world"
>like apps that weight 30MB, half giga is 15m download...even here in the
>ass of the world (small town Argentina)
>
>As for porting Gambas, it will be really good.  I have the time (but not
>the brain) to help anyone that joins the party and has the know-how for
>a start.
>
>
> > Le 01/11/2013 11:33, François Gallo a écrit :
> >
> > >
> > > Le 01/11/2013 11:15, Fabien Bodard a écrit :
> > >> After long talk with many gambas developpers, after years of joy on
> > the use
> > >> of this language, I want to talk about its future... its persistance.
> > >>
> > >>
> > >> Benoit for me is a little bit like our Linus. He have done
> > something for
> > >> itself and it's today one of the better tool ever see. (Umm ... ;-))
> > >>
> > >> Now, for me one thing lock down Gambas... why can't it be more known ?
> > >> Because it is close to Linux world. Theire is no possibility to use it
> > >> natively on other system ... this problem what explicitely exposed
> > by RMS
> > >> in the past in a mail sended to us. Yes in his request he wanted us
> > to make
> > >> the interpreter generate a cil code for interpreter like java/.net or
> > >> parrot. Well today we know java isn't a sure way, and we can do
> > things too
> > >> without.
> > >>
> > >> I have a request to Benoit, and i know it's time is precious and
> > like mine
> > >> rare. I want him to concentrate on make it's code portable... separate
> > >> specific linux part to allow all our friend that want to help to port
> > >> gambas to stars to make theire job.
> > >>
> > >> By doing this, most people can participate on compiler/interpreter
> > code, by
> > >> having Gambas on other system we can have more component
> > maker/maintainer.
> > >> At the end Benoit can take hollidays and come take a Cognac at home
> > .   :-)
> > >>
> > >> I know this is a huge job as he/we need to take the time to mark
> > all part
> > >> of the code that is hard linked on Linux system, and then choose a
> > way to
> > >> separate it to symplify the maintainment
> > >>
> > >> Same thing for the toolkits but it's at a first time not the
> > subject of
> > >> today.
> > >>
> > >> Now we have hands that can help... but it can't be done if the code
> > is not
> > >> structured for.
> > >>
> > >> So for the Undred time ... Benoit ... Please, let us helping you.
> > >>
> > >>
> > >>
> > >>
> > >> To all, the gambas user/dev, this exchange is for you so even if it
> > take
> > >> thouthen of mail, please give us your impress and your ideas, your
> > support.
> > >>
> > >>
> > >>
> > >> Please, don't look at the spelling fault, it will take to many time
> > to you
> > >>     ;-)
> > >>
> > >>
> > >>
> > >
> > > Fabien's right!
> > >
> > > i worked on gambas' portability (OS X and *BSD) and i can say
> > > we need a new structure of code to make a good portability
> > > but mainly a proper maintenance.
> > >
> > > Gambas is too linked to Linux. I can understand Benoit isn't
> > > interesting to spend time in the developing to port Gambas,
> > > but Benoit MUST review its code.
> > >
> > > At the moment, Gambas is not coded to port properly on
> > > others OS.
> > > a lot of routines is too linked to Linux (i say it again).
> > >
> > > Add new components and features is great, but it is
> > > preferable to focus time to make it better.
> > >
> > > i hope a work will be done in the gambas code to have
> > > a "modular code". Separate X11 in a single code is
> > > better for us, developers who wants to work on
> > > portability of Gambas!
> > >
> > > in this manner, each developer can works on a code
> > > for OS X, for Windows and so on ...
> > > X11 for OS X is ugly.
> > > X11 for Windows is ugly.
> > > Use translated X11 routines are ugly.
> > >
> > > Benoit, we don't ask you to port Gambas to OS X & Windows,
> > > just to re-structure code of Gambas so that we can works
> > > efficiently!
> > >
> > > While this change will not be applied,
> > > i would not be motivated to work on any Gambas port again...
> > >
> > « [hide part of quote
> > 
> <http://gambas.8142.n7.nabble.com/Gambas-Future-or-what-kind-of-Gambas-we-want-td44034.html#>]
> >
> > To port Gambas on non-X11 systems, the problems are the following:
> >
> > 1) The interpreter relies on some kernel features that are not exactly
> > implemented in the Windows kernel, especially the fork() system call.
> > The Cygwin emulation layer is too slow.
> >
> > 2) I don't care about Windows. Doing the port is a big job. I started to
> > did it on Windows XP + Cygwin years ago. It worked, but there was the
> > fork() system call emulation that was slow.
> >
> > 3) There is X11 code in gb.gtk, gb.qt4 and gb.desktop.
> >
> > 4) For gb.gtk: as GTK+ 2 is deprecated, gb.gtk should be ported to GTK+
> > 3. This implies removing all the X11 specific code.
> >
> > 5) For gb.qt4: the X11 specific code is there to workaround some
> > problems, but should not exist theoritically.
> >
> > 6) For gb.desktop: the desktop routines relies on the X11 window manager
> > protocols and freedesktop.org standards. A lot of things cannot be
> > ported, but some things can.
> >
> > 7) Many components are interfaces to libraries that do not necessarily
> > exist on other systems. It could be a problem.
> >
> > I think there is not a lot of thing to do to port the interpreter, the
> > compiler and the other tools, as I already did that on Windows.
> >
> > As for the X11 stuff, of course you're right. It must be encapsulated
> > somewhere so that it can be easily replaced. I already planned to do
> > that, but never had the time.
> >
> > At the moment, I'm busy with fixing Gambas packager as soon as possible,
> > so that a Gambas 3.5.1 could be released.
> >
> > --
> > Benoît Minisini
>
>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today.
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>_______________________________________________
>Gambas-user mailing list
>Gambas-user at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/gambas-user

Carl S Nilsson
137 Gordons Hill Road
Lindisfarne, Tas.
Australia 7015