gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] I want to create community code, not another islan


From: Brian Tiffin
Subject: Re: [open-cobol-list] I want to create community code, not another island
Date: Tue, 3 Sep 2013 03:09:58 -0400

Patrick;  We're going to get 2.0 released soon.  User Defined
Functions are grand.

But, I'd buy into a Corba style marshal / unmarshalling system,
regardless.  It can be a fair amount of grunt case by case marshal
though.

Or, at a high level, COBOL linkage allows for record structures.  As
long as everyone is in alignment, you can CALL using record-thing.

01 record-thing.
    05 sub-records occurs 8 times.
         10 sub-field1 pic 9.
         10 sub-field2 pic x(40).

etc, for as complex a structure as you'd like.  But, things need to align.

Reading through the source code behind CALL may lead you to some nice
solutions to a generic marshalling system.

cob_field traversal from C can be pretty powerful too.

Another angle is SWIG and eventually (I hope) is something like full
on glib introspection.  (Yet another reason to document cob_field).

See the S-Lang entry (or Pure) in the OC FAQ for some ways of using
before hand knowledge of data types and calling explicit conversion
routines too.  Those might hint at paths to a fairly clean solution.

Seeing your sample, REBOL PARSE would be great at this, but r3 isn't
quite ready, and r2 doesn't provide access to the last-value stack so
the embedding sample was "for side effect only", not value passing
back and forth.

Cheers,
Brian

On 9/2/13, Patrick <address@hidden> wrote:
> Hi Everyone
>
> I've received so much help since January when I started with Cobol.
>
> I still have lots to learn but I think I know enough now to get my main
> project under-way in Cobol(with C++ front end), in pertains to
> controlling scientific instruments.
>
> I have been reading up and tinkering with termios on Linux and reading
> about dcb on windows. i am going to try to make a cross platform serial
> port library now. After that I am going to work on socket and winsock to
> create a cross platform socket library. After this I may be working with
> XML, OpenGL, Imagemagick, sqlite and others. I've decided that I will
> have to limp along for a year or two and use C++ and QT as a front end
> but I would really like to use a full Cobol gui binding and maybe a
> couple years from now I will try to tackle this.
>
> I hope I won't upset anyone with an editorial, please don't get mad,
> it's motivated by the desire to help....
>
> Cobol is so neat and there is supposed to be so much of it written but
> it seems that most Cobol people have not formed communities like ours
> and Governments and companies have used it to create codebase "islands".
> There are minimal tools to share code between unknown parties and things
> are worse with C. Sure we can use call statements but so many of them
> are required to make a binding and I don't see any standard way to
> organize them for use by unrelated parties later. It seems like Cobol
> has done very well in the business world but never really branched into
> other fields. Everything you need for business is built in but it just
> does not have "import" from python, "with" from Ada or some other
> keyword to bring in C code in a tidy way.
>
> I know there will be user defined functions one day but we don't really
> have a lead developer right now. I want to help but it's kind of like
> the student writing the text books for the teachers right now. My C/C++
> is really ramping up but it will still be several months before I can
> contribute anything and then, will I have time to create the mechanisms
> that I wish were there, probably not.
>
> I have been toying with the idea of a super procedure as a module to be
> shared.
>
> I think I have a working format but I don't have to ask anyone if they
> will like it, I know it will be totally unacceptable to the community as
> it's more like forth then cobol.
>
> So one piece of equipment I need to control mixes four different
> solvents. It mixes them in different proportions over time, creating a
> solvent gradient.
>
> So if I had a table that had 5 fields, time, solvent A, B, C D, I could
> send a strings to each record like:
>
> 1.00 25 35 35 15
> 2.00 10 10 10 70
> 3.00 25 25 25 25
>
>
> However there are many other things that need to be controlled with this
> instrument like pumping flow rate and helium mixing.
>
> I will need to create procedures for each of these other topics but I
> would like each to be a sub-procedure contained within a super procedure.
>
> Right now I am playing with a scheme that would work like this:
>
> A single string would be sent to the super procedure.  Inside the super
> procedure, a stack manager would examine the string and see if it is
> data and if so, it would push it on the stack. Later another call would
> be sent containing the name of a sub-procedure. The stack manager would
> see it it as the name of a procedure and not data and it would call it
> passing the previous value on the stack with it. The sub-procedure would
> then take the string from the stack, split it and move it into a record
> and then use it in a conventional manner.
>
> I was thinking that the stack manager could take chunks of strings like
> this:
>
>
> 1.00 25 35 35 15 !!
> 2.00 10 10 10 70 !!
> 3.00 25 25 25 25 ;;
> gradient ;;
>
> and process them spiting tokens on ;; and the sub-procedures would then
> split on !!
>
> I bet this will work but there is no way that anyone else would want to
> use this.
>
> Can anyone help me come up with a scheme that is more cobol-like?
>
> My idea is crazy looking but it would also allow the super procedure to
> be entirely coded in C or another language, I think this is critical.
> The library code does not need to be cobol. It would save a lot of
> trouble if the super procedure was useable from Cobol but written in C.
>
> If there was some format that we could all(or most of us) agree on, it
> could become the basis for sharing code(at least in the interim) and not
> just cobol code but code that is or binds to C
>
> Thanks for reading this long email-Patrick
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]