On Tue, 12 Jun 2012, Rolf-Werner Eilert wrote:
> Am 12.06.2012 13:41, schrieb Benoît Minisini:
> > Le 12/06/2012 13:01, jm a écrit :
> >> On Tue, 2012-06-12 at 12:03 +0200, Rolf-Werner Eilert wrote:
> You already have at your disposal a program which fully understands
> what to do with #i
> Le 12/06/2012 16:30, jm a écrit :
>>
>> Any chance of exporting IDE's highlighted code as colorful HTML
>> for documentation purposes?
>>
As for that, it is not very difficult to implement, as you have access
to the internal Gambas highlighter through the gb.eval component.
I will see if I can
Le 12/06/2012 16:30, jm a écrit :
>
> I take it that is a definite no then? :-)
>
> If I'm really under pressure, then I'm sure I can go
> write a lite preprocessor as needed and manage.
>
> Any chance of exporting IDE's highlighted code as colorful HTML
> for documentation purposes?
>
> Thank you,
Do you need the syntax highlighting to be baked in? Can you not just
use Kate (in KDE) or Gedit with a suitable set of rules for their
existing highlighting mechanisms?
I remember a few years ago when I was using Gambas in a project for my
night-class in software engineering I was able to get synt
> Yes, automatic completion would mean browsing all #included files each
> time to search for keywords, but how do IDEs for C programming handle this?
Netbeans and Eclipse do handle it 'reasonably' well.
__
This messa
I don't know about Gambas but Python has many libraries for this. Just
google it. If you insist on pre-processing, a simple python script could
get it done quickly. I'm a firm believer in using the tool that makes the
most sense for the project. Of course, that depends on the person and
project
On Tue, 2012-06-12 at 13:41 +0200, Benoît Minisini wrote:
> Le 12/06/2012 13:01, jm a écrit :
> > On Tue, 2012-06-12 at 12:03 +0200, Rolf-Werner Eilert wrote:
> >>> You already have at your disposal a program which fully understands
> >>> what to do with #include (and all the other pre-processor di
Am 12.06.2012 13:41, schrieb Benoît Minisini:
> Le 12/06/2012 13:01, jm a écrit :
>> On Tue, 2012-06-12 at 12:03 +0200, Rolf-Werner Eilert wrote:
You already have at your disposal a program which fully understands
what to do with #include (and all the other pre-processor directives
w
Am 12.06.2012 13:41, schrieb Benoît Minisini:
> Le 12/06/2012 13:01, jm a écrit :
>> On Tue, 2012-06-12 at 12:03 +0200, Rolf-Werner Eilert wrote:
You already have at your disposal a program which fully understands
what to do with #include (and all the other pre-processor directives
w
Le 12/06/2012 13:01, jm a écrit :
> On Tue, 2012-06-12 at 12:03 +0200, Rolf-Werner Eilert wrote:
>>> You already have at your disposal a program which fully understands
>>> what to do with #include (and all the other pre-processor directives
>>> which have been mentioned). Have you tried it out yet
On Tue, 2012-06-12 at 12:03 +0200, Rolf-Werner Eilert wrote:
> > You already have at your disposal a program which fully understands
> > what to do with #include (and all the other pre-processor directives
> > which have been mentioned). Have you tried it out yet?
> >
>
> Is it possible to insert
> You already have at your disposal a program which fully understands
> what to do with #include (and all the other pre-processor directives
> which have been mentioned). Have you tried it out yet?
>
Is it possible to insert the C pre-processor into the Play-Button
function of the Gambas IDE, ma
Richard,
You got same ideas I got!
I was going to write a gambas program to do the preprocessing, but
backed off because the issue then became which programs do you maintain?
The expanded ones that the IDE can run or the compact ones
edited in a text editor without highlighting.
Lack of highligh
With apologies to all-who-know-more-about-this-than-me (or just "all")...
Joe, you have a problem with managing a growing Gambas codebase and
you think having an #include method in Gambas would help you cope. We
are agreed that if it were added then it would operate before the
compiler kicks in to
> Gambas provides file management for it's projects. Using Gambas you can get
> file management for free by splitting a project into many classes which in
> Gambas results in the IDE managing these as different files. This is not
> necessarily the case with other OOP languages.
>
OK, now I think I
On Mon, 11 Jun 2012, Jussi Lahtinen wrote:
> > As I see it include is a pre-processing directive. It simply replaces the
> > #include statement with
> > the contents of an external file. This is a project management
> > consideration and not a programming paradigm i.e. OOP, Functional,
> > Procedur
Hi Jussi,
I don't think that OOP by itself replaces #includes. No more than OOP would
replace SVN, CVS, Merc, etc.. Look at any reasonably sized C/C++ project
and you'll see plenty of includes. I think the real issue here is the
language choice.
Gambas provides file management for it's projects.
> As I see it include is a pre-processing directive. It simply replaces the
> #include statement with
> the contents of an external file. This is a project management
> consideration and not a programming paradigm i.e. OOP, Functional,
> Procedural, etc..
I agree, but I think with OOP, C style #i
Hi Folks,
Thought I would chime in on this issue. As I see it include is a
pre-processing directive. It simply replaces the #include statement with
the contents of an external file. This is a project management
consideration and not a programming paradigm i.e. OOP, Functional,
Procedural, etc.. Th
I think this;
"object1.object_within_object.object_within_that_object.method(parameters1,..)"
can be avoided with good object design. I still can't see real usage for
#include.
Also should be noticed that new keywords are justified only if they have
general usage.
But after all this is decision of
Hi Bruce,
The broadest difference between #include (and its cousins #define,
#undefine, #ifdef, #ifndef and #endif) and OO programming is that
#include is a preprocessing command that gets to work long before a
program gets to run.
Using #include and its cousins, the idea is to build big readable
Thank you Jussi.
That is just fantastic example that I intend to use for new projects.
The point I am trying to make should not have to become an OO v non-OO
programming debate.
The broadest difference is that #include and its cousins (#define,
#undefine, #ifdef, #ifndef, #endif) are to do with
OK, while that solution might work, it sucks.
Instead see new attachment (IncludeProblem-2.0.tar.gz).
Jussi
On 9 June 2012 16:57, Jussi Lahtinen wrote:
> Thinking more closely your problem, I think I know what you need.
>
> You try to avoid writing *many* lines like this;
> sParameterNameArra
Sorry, maybe I need to re-read!
Jussi
On 9 June 2012 18:02, Jussi Lahtinen wrote:
> Bruce, please re-read. I'm against idea of #include being new keyword.
>
> Jussi
>
>
>
>
> On 9 June 2012 17:00, Bruce wrote:
>
>> On Sat, 2012-06-09 at 13:51 +0100, jm wrote:
>> > On Sat, 2012-06-09 at 02:45
Bruce, please re-read. I'm against idea of #include being new keyword.
Jussi
On 9 June 2012 17:00, Bruce wrote:
> On Sat, 2012-06-09 at 13:51 +0100, jm wrote:
> > On Sat, 2012-06-09 at 02:45 +0300, Jussi Lahtinen wrote:
> > > Maybe I'm just too tired, but I don't understand the point.
>
> Jus
On Sat, 2012-06-09 at 13:51 +0100, jm wrote:
> On Sat, 2012-06-09 at 02:45 +0300, Jussi Lahtinen wrote:
> > Maybe I'm just too tired, but I don't understand the point.
Jussi, maybe I'm just too old as well as tired, but I can't grasp the
point of taking an object oriented language and trying to ja
Thinking more closely your problem, I think I know what you need.
You try to avoid writing *many* lines like this;
sParameterNameArray = NEW String[MAXIMUM_CSV_PARAMETERS]
That is caused by broken object design, usually because you need to use old
code which had different approach than OO.
I have
> C thrives on #include without showing signs of design problems.
>
Yes, I know, I wasn't talking about C, I was talking about object oriented
language, Gambas.
> Tens of thousands of external lines of code can be pulled in with
> a dozen #include statements, leaving the code completely manage
On Sat, 2012-06-09 at 02:45 +0300, Jussi Lahtinen wrote:
> Maybe I'm just too tired, but I don't understand the point.
>
> If you have huge program that needs to be expended just a little bit,
> then why don't you just add new class/module/piece of code/etc which holds
> that new thing to the prog
Maybe you need to use Export?
http://gambasdoc.org/help/lang/export?v3
Jussi
On 9 June 2012 01:16, jm wrote:
> C like #include files for gambas?
>
> Sounds a bit harsh I know, but is it possible to add a feature
> that functions like a C #include?
>
> The logic behind is to address programs t
well in gambas you can include differently afaik
try turning on and off: project --> properties --> components
if you don't have some turned on you can't do some stuff
jm-24 wrote:
>
> C like #include files for gambas?
>
> Sounds a bit harsh I know, but is it possible to add a feature
> that
Maybe I'm just too tired, but I don't understand the point.
If you have huge program that needs to be expended just a little bit,
then why don't you just add new class/module/piece of code/etc which holds
that new thing to the program?
Or if you need something from the program like "#include your
C like #include files for gambas?
Sounds a bit harsh I know, but is it possible to add a feature
that functions like a C #include?
The logic behind is to address programs that are growing
out of control in size. These are working megalithic programs that
have had years of code piled on top of oth
33 matches
Mail list logo
