[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] Daydreaming about another language to emit
From: |
Brian Tiffin |
Subject: |
Re: [open-cobol-list] Daydreaming about another language to emit |
Date: |
Sat, 5 Oct 2013 11:14:22 -0400 |
I'll just pipe up a little.
Patrick; because of Sergey's C++ emit implementation, it'll be pretty
easy now to figure out how to emit other code. Java might make some
people happy.
I'm actually amazed how readable GNU Cobol machine generated C is.
Beats Vala and Algol68g (two other C emit systems) hands down.
Charles; LLVM. We do clang. Build compiler with clang, generated
code compiled with clang. All worked first try. One small compiler
switch change meant ALL the make check passes as well.
http://opencobol.add1tocobol.com/#does-opencobol-work-with-llvm
When we implement --with-guile as a ./configure option I'd like to
implement the internals with EXEC GUILE
...
END-EXEC
(we have ocesql for 'code method' scaffolding now, so yayys)
Once that is in place, along with having Guiles' LISP and ECMAScript
(and bf, but I doubt an auditor would appreciate decoding bf in a
financial application) we'll have a framework to implement just about
any
EXEC engine ... END-EXEC
paragraphs that we can imagine.
Patrick; keep thinking along these lines. There may well be a GNU
Cobol -> Node.js emitter someday. But for the now, C and C++ are
options, and once FUNCTION-ID is ubiquitous, a lot of need for CALL
can be removed as well.
Things like
MOVE FUNCTION PASCAL-SUB(args) TO COBOL-VAR
is just over the horizon.
And I'll ditto VBISAM. I'd like to pester Trevor to see if he'd be up
for GNU-ification of VBISAM, and then let it loose on the world as
well, released along with GNU Cobol source tree.
Cheers,
Brian
On 10/4/13, Sergey Kashyrin <address@hidden> wrote:
> VBISAM
>
> We just need a people who can fix some locking issues on unix.
>
> Cheers,
> SK
>
> On 10/4/2013 10:46 PM, Michael Potter wrote:
>> I think getting rid of BDB is a great idea.
>>
>> It would make OpenCOBOL more commercially viable to implement this
>> interface:
>> http://supportline.microfocus.com/documentation/books/sx20books/fhexfh.htm
>>
>> Microfocus allows their users to replace their file handler by
>> implementing to that specification.
>>
>> Fujitsu and COBOL-IT implemented the same interface for the compilers
>> they sell.
>>
>> My implementing that interface, it would make it easier for people to
>> port from those compilers to OpenCOBOL.
>>
>> I have implemented a couple of file handlers that "plug in" to
>> microfocus. Their system works well.
>>
>> Note: I am giving credit to microfocus for inventing this interface,
>> but I have the feeling it was invented somewhere else.
>>
>> The implementation would go something like this:
>> 1) Implement EXTFH interface in OpenCOBOL.
>> 2) Implement EXTFH wrapping BDB.
>>
>> as this point existing user could continue to use the BDB data, but
>> have the flexibility to add new EXTFH that access data in other backends.
>>
>> I had one of my programmers replace BDB in OpenCOBOL so I could be
>> compatible with MicroFocus as part of my OpenKicks framework. It
>> would make a good starting point for this effort. We basically wrote
>> a library with same interface as BDB and linked it into OpenCOBOL.
>> Don't get your hopes up that it will be very useful for this effort.
>>
>> I will look into making that open source so you can use it in
>> OpenCOBOL, much like I open sourced EZASOKET
>> http://code.google.com/p/ezasoket/.
>>
>>
>> On Fri, Oct 4, 2013 at 5:15 PM, Patrick
>> <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>> On 10/04/2013 04:31 PM, Michael Anderson wrote:
>> > On 10/04/2013 02:42 PM, Patrick wrote:
>> >> I did say that I was just hoping to have a theoretical chat and
>> that I
>> >> was not saying we had to change anything. Calling my comments
>> >> ridiculous isn't very chatty
>> > Sorry Patrick, I am often hurtfull in my choice of words, I
>> didn't mean
>> > to ofend you, or anyone.
>> > But you're a are right, it does not enable a good theoretical chat.
>> > I'll try to choose better words in the future.
>> >
>> > --
>> > Mike.
>> > We are all sharing this planet together, we should all try
>> harder to get
>> > along.
>> >
>> Hi Mike
>>
>> Not to worry.
>>
>> I keep doing this over and over again, I have to learn.
>>
>> I don't have any friends, co-workers or family that I can talk about
>> programming with.
>>
>> I bet I have posted to more then 40 different mailing lists over the
>> past 7 years.
>>
>> Every time I just want to just chat things go bad. I guess mailing
>> lists
>> are for black & white, "how is this done" sort of questions and
>> not just
>> friendly coffee time like chatter.
>>
>> Have a great day !
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get
>> the most from
>> the latest Intel processors and coprocessors. See abstracts and
>> register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> open-cobol-list mailing list
>> address@hidden
>> <mailto:address@hidden>
>> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>>
>>
>>
>>
>> --
>> Michael Potter
>> Tapp Solutions, LLC
>> Replatform Technologies, LLC
>> +1 770 815 6142 ** Atlanta ** address@hidden
>> <mailto:address@hidden> ** www.linkedin.com/in/michaelpotter
>> <http://www.linkedin.com/in/michaelpotter>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> open-cobol-list mailing list
>> address@hidden
>> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>
>
- Re: [open-cobol-list] Daydreaming about another language to emit, (continued)
- Re: [open-cobol-list] Daydreaming about another language to emit, Charles Anthony, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit, Michael Anderson, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit, Patrick, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit, Michael Anderson, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit, Patrick, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit, Michael Potter, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit, Sergey Kashyrin, 2013/10/04
- Re: [open-cobol-list] Daydreaming about another language to emit,
Brian Tiffin <=
- Re: [open-cobol-list] Daydreaming about another language to emit, Sergey Kashyrin, 2013/10/05
- Re: [open-cobol-list] Daydreaming about another language to emit, David L Lambert, 2013/10/06
- Re: [open-cobol-list] Daydreaming about another language to emit, Patrick, 2013/10/06
- Re: [open-cobol-list] Daydreaming about another language to emit, Patrick, 2013/10/07
- Re: [open-cobol-list] Daydreaming about another language to emit, Patrick, 2013/10/05
- Re: [open-cobol-list] Daydreaming about another language to emit, Vincent Coen, 2013/10/05
- Re: [open-cobol-list] Daydreaming about another language to emit, Michael Anderson, 2013/10/05
- Re: [open-cobol-list] Daydreaming about another language to emit, Patrick, 2013/10/05
- Re: [open-cobol-list] Daydreaming about another language to emit, Charles Anthony, 2013/10/05
- Re: [open-cobol-list] Daydreaming about another language to emit, Brian Tiffin, 2013/10/06