Re: [U2] A new DML?
This all comes back to my point that Rocket do have a responsibility to make it easier to write the language bindings. The reason mongodb has so many is that the developers released a well document low level api with examples that most programmers could work from to create a binding. Intercall is probably the best we get from rocket, (as you say uo is not the way to go as it is not low level, but uo is built on intercall i believe) So can rocket provide better documentation and an example set for intercall ,or whatever is best suited to produce a language binding - i suspect not ! From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 07 February 2011 20:58 To: u2-users@listserver.u2ug.org Subject: Re: [U2] A new DML? From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3428 - Release Date: 02/07/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
I guess Ian was partially right? On jbase, all basic code is precompiled into c code (which is then compiled into os native object and executables), and if you wanted to you could just skip the precompiler and write the c code directly. They provide object code libraries with functions for all the basic statements and intrinsic functions. Intercall on unidata and gci on universe are somewhat similar though they aren't as simple to use as on jbase. On Feb 7, 2011, at 7:13 PM, fft2...@aol.com wrote: RPL was a new language binding, which developed from PROC. It was a fully extended language, capable of replacing BASIC in all regards. I wonder if anyone is still running an RPL system anywhere? Another note, per Ian Sandler, writing in or just before 1989, which might be seen as humorous or not... A C compiler will no doubt become widely available for PICK soon. [He always uses 'PICK' not 'Pick'.] Several already exist in various stages of completeness. He then goes on to describe a way to get C code to run anyway. You write it for the specific processor. Then transfer the compiled code to tape. Load the tape on your Pick system and it will execute. He states that he does this. I've never heard of anyone doing this actually. It sounds rather laborious. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. Not from universe/unidata/d3 maybe (and sadly), but this is what Intersystems did with Cache. They added mv basic as a language in the dbms (beside the original object script/M language and a vb style cache basic) along with object bindings to .net, java, C, and others. On Feb 7, 2011, at 11:16 PM, Glen B wrote: On 2/7/2011 3:58 PM, Tony Gravagno wrote: From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T As an end-user developer, you probably won't find much interest. There's too much to do with the core business code as it is. Would it make life easier for the few solutions developers who actually might want it? I know I've wanted similar gut hooks for my own oddball projects but I have always found a way to make things happen without it. Just because we're clever enough to connect points A and B, though, doesn't mean we should simply accept that the steps involved always be convoluted and the process numbingly inefficient. Do the DBMS vendors not care about making the solutions-providing developer's lives easier? Who really sells their product? How many forward-thinking developers have left MV because these should-haves never have existed. How many migrations have happened due to a small subset of those must-haves have popped up in another flavor? GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/8/2011 8:38 AM, Ed Clark wrote: I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. Well, the python on my aix box is a little crufty (2.6.2). Ctypes is malfunctioning so I will probably be a quarter or two out from tinkering with this. I see 2.7.1 rpms for aix 6.1, but not 5.3. I may try to compile it from src, but again, my time is limited at the moment. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/8/2011 8:41 AM, Steve Romanow wrote: On 2/8/2011 8:38 AM, Ed Clark wrote: I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. Well, the python on my aix box is a little crufty (2.6.2). Ctypes is malfunctioning so I will probably be a quarter or two out from tinkering with this. I see 2.7.1 rpms for aix 6.1, but not 5.3. I may try to compile it from src, but again, my time is limited at the moment. I did get 2.7.1 built from src, but ctypes failed to build, so it is in the same shape as my 2.6.2. Still glad to get 2.7 for other reasons though. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 08/02/11 13:38, Ed Clark wrote: I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. Not from universe/unidata/d3 maybe (and sadly), but this is what Intersystems did with Cache. They added mv basic as a language in the dbms (beside the original object script/M language and a vb style cache basic) along with object bindings to .net, java, C, and others. That was, to the best of my knowledge, Jim Idle's work (yup, the jBase guy). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 07/02/11 21:00, Steve Romanow wrote: Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T I think I will be tinkering with this soon. I have to believe Intercall should give the best perfomance available, since it is at the lowest level. LibreOffice is looking for a new database ... my problem is finding time, but I'd love to write a new NF2 database for it :-) What sort of impact is an MV database going to have if it goes into something like that :-) Contact me off-line if you want to muck in :-) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/8/2011 10:28 AM, Wols Lists wrote: On 07/02/11 21:00, Steve Romanow wrote: Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T I think I will be tinkering with this soon. I have to believe Intercall should give the best perfomance available, since it is at the lowest level. LibreOffice is looking for a new database ... my problem is finding time, but I'd love to write a new NF2 database for it :-) What sort of impact is an MV database going to have if it goes into something like that :-) Contact me off-line if you want to muck in :-) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I think my progress is stopped. It appears libffi (which ctypes uses) may be windows and linux only. Unless I can get confirmation of aix functionality, my plan stops here. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/7/2011 11:48 PM, Steve Romanow wrote: How many companies sole source of income is from innovation and investment from 2-3 decades and 6 owners ago? ___ I know of many but they each have their own varying level of innovation due to varying focuses. What are you getting at? GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/8/2011 10:34 AM, Glen B wrote: On 2/7/2011 11:48 PM, Steve Romanow wrote: How many companies sole source of income is from innovation and investment from 2-3 decades and 6 owners ago? ___ I know of many but they each have their own varying level of innovation due to varying focuses. What are you getting at? GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users That IBM and Informix cared not a whit about mv. Rocket has yet to be seen. I also see it with the new (5 or so years now) owner of my ERP. They are making a living selling a software product written by architects long gone. I don't think they are committed to making it better or cleaning up very much at all. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/8/2011 10:30 AM, Steve Romanow wrote: On 2/8/2011 10:28 AM, Wols Lists wrote: On 07/02/11 21:00, Steve Romanow wrote: Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T I think I will be tinkering with this soon. I have to believe Intercall should give the best perfomance available, since it is at the lowest level. LibreOffice is looking for a new database ... my problem is finding time, but I'd love to write a new NF2 database for it :-) What sort of impact is an MV database going to have if it goes into something like that :-) Contact me off-line if you want to muck in :-) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I think my progress is stopped. It appears libffi (which ctypes uses) may be windows and linux only. Unless I can get confirmation of aix functionality, my plan stops here. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users It's available on AIX for PPC-64 based on the home page. GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/8/2011 10:41 AM, Glen Batchelor wrote: It's available on AIX for PPC-64 based on the home page. GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Ty, so there is some hope. I need to work on assigned work a bit. Will try to pick this up later. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
It is clear to me that we have been for some time in an era of middleware. Some examples... Flex - ColdFusion - database Ajax - pHp - SQL SB+ - UniBasic - U2 FrontEnd - MiddleWare - database GUI - BusinessLogic - database With the emerging preponderance of devices, phones, tablets, PC's, the trend towards three tiers is... forever. It is like the holy trinity of computing. Although I am mainly interested in the NOW, I try to make it a point to encourage others to get sentimental... about the future. --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Mobile computers and phones of today are ushering in a new stage of complexity and power that has changed the overall scope of what client/server means. Mobile devices used to be moderately-powered slaves that represented a UI, comm hook or data batching portal for a server that did all of the lifting. You can no longer look at a mobile device and consider it a client since it has all 3 layers on it itself. They are, in essence, micro-servers with user friendly control panels and touch screens. You now have to consider development as both client/server and server/server depending on the solution. Glen Batchelor IT Director/CIO/CTO All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: webmas...@all-spec.com Web: http://www.all-spec.com Blog: http://blog.all-spec.com -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Brutzman Sent: Tuesday, February 08, 2011 10:44 AM To: U2 Users List Subject: Re: [U2] A new DML? It is clear to me that we have been for some time in an era of middleware. Some examples... Flex - ColdFusion - database Ajax - pHp - SQL SB+ - UniBasic - U2 FrontEnd - MiddleWare - database GUI - BusinessLogic - database With the emerging preponderance of devices, phones, tablets, PC's, the trend towards three tiers is... forever. It is like the holy trinity of computing. Although I am mainly interested in the NOW, I try to make it a point to encourage others to get sentimental... about the future. --Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Only in part. Intersystems has many developers, all developing away. I'm trying not to sound like an advertisement here--just making the point that innovation is actively happening on at least 1 mv platform. On Feb 8, 2011, at 10:26 AM, Wols Lists wrote: On 08/02/11 13:38, Ed Clark wrote: I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. Not from universe/unidata/d3 maybe (and sadly), but this is what Intersystems did with Cache. They added mv basic as a language in the dbms (beside the original object script/M language and a vb style cache basic) along with object bindings to .net, java, C, and others. That was, to the best of my knowledge, Jim Idle's work (yup, the jBase guy). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Development doesn't necessarily equate to innovation. U2 is under constant development, but I wouldn't count much of it as innovation, just (slowly) trend following. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Ed Clark Sent: Wednesday, 9 February 2011 11:01 AM To: U2 Users List Subject: Re: [U2] A new DML? Only in part. Intersystems has many developers, all developing away. I'm trying not to sound like an advertisement here--just making the point that innovation is actively happening on at least 1 mv platform. On Feb 8, 2011, at 10:26 AM, Wols Lists wrote: On 08/02/11 13:38, Ed Clark wrote: I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. Not from universe/unidata/d3 maybe (and sadly), but this is what Intersystems did with Cache. They added mv basic as a language in the dbms (beside the original object script/M language and a vb style cache basic) along with object bindings to .net, java, C, and others. That was, to the best of my knowledge, Jim Idle's work (yup, the jBase guy). Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB. ### ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/7/2011 3:58 PM, Tony Gravagno wrote: From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users I think I will be tinkering with this soon. I have to believe Intercall should give the best perfomance available, since it is at the lowest level. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Tony I'm not sure this could be true about RPL which is now only available for D3 with variants in jBase and Reality RPL was written initially I believe for the Reality, but was ported as well to Ultimate and *I believe* to MvBase as well. You can still, as far as I can see, get a new Ultimate install, although today they call it Ult-Plus. Are you certain that they do not support RPL being used on the Ultimate system? I'm not saying that they have actually *sold* any in the past five years, just that it seems like they could. Speaking of, the company that wrote RPL might make a good addition to the Pick History series. I learned RPL before I really learned BASIC. -Original Message- From: Tony Gravagno 3xk547...@sneakemail.com To: u2-users u2-users@listserver.u2ug.org Sent: Mon, Feb 7, 2011 12:58 pm Subject: Re: [U2] A new DML? From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
RPL was a new language binding, which developed from PROC. It was a fully extended language, capable of replacing BASIC in all regards. I wonder if anyone is still running an RPL system anywhere? Another note, per Ian Sandler, writing in or just before 1989, which might be seen as humorous or not... A C compiler will no doubt become widely available for PICK soon. [He always uses 'PICK' not 'Pick'.] Several already exist in various stages of completeness. He then goes on to describe a way to get C code to run anyway. You write it for the specific processor. Then transfer the compiled code to tape. Load the tape on your Pick system and it will execute. He states that he does this. I've never heard of anyone doing this actually. It sounds rather laborious. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Have a look at Antler - http://www.antlr.org/ and http://pragprog.com/titles/tpdsl/language-implementation-patterns I have also looking into this as a method to extend UniBasic with a pre-processor. djm slestak wrote: I think I will be tinkering with this soon. I have to believe Intercall should give the best perfomance available, since it is at the lowest level. - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Re%3A-UUID--was-Data-in-Dict--tp30772851p30869344.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/7/2011 3:58 PM, Tony Gravagno wrote: From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T As an end-user developer, you probably won't find much interest. There's too much to do with the core business code as it is. Would it make life easier for the few solutions developers who actually might want it? I know I've wanted similar gut hooks for my own oddball projects but I have always found a way to make things happen without it. Just because we're clever enough to connect points A and B, though, doesn't mean we should simply accept that the steps involved always be convoluted and the process numbingly inefficient. Do the DBMS vendors not care about making the solutions-providing developer's lives easier? Who really sells their product? How many forward-thinking developers have left MV because these should-haves never have existed. How many migrations have happened due to a small subset of those must-haves have popped up in another flavor? GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 02/07/2011 11:16 PM, Glen B wrote: On 2/7/2011 3:58 PM, Tony Gravagno wrote: From: Charles_Shaffer You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. We use Uniobjects on our web servers to access our Unidata servers. Technically we could avoid UniBasic with Uniobjects, although I don't recommend it. It has makes more sense to push the database logic to the database server using Unibasic routines called by Uniobjects. I'll interject that there are two discussions going on here: language bindings outside the DBMS, connecting in via whatever pipes happen to be available (UO, C, Intercall, sockets, etc), and language bindings built into the DBMS alongside BASIC. I'll go on a limb and state my belief emphatically that we will never see another new language implemented within the DBMS itself. (The only other language I've ever seen built over MV was RPL (PQN+), which is now only available for D3 with variants in jBase and Reality). The DBMS vendors have no motivation to undertake the massive effort of creating a new compiler and runtime to operate over the DBMS engine. Claims of new sales potential with mainstream languages can't be substantiated; We obviously already have external bindings and MV sales have never spiked because of it. Now, as I've said recently, we can immediately build our own external language bindings with no help from any of the DBMS providers. Unfortunately this option leaves us to connect in via the above methods, and no matter how fast that happens, it's subject to a performance hit. A much more elegant solution would be an API that dynamically links with the DBMS monitor to perform direct read/write/call and other operations. Maybe someone can tell us if the UO server component really is this closer to the metal interface, but it's always seemed to me that even that server component is one step and a performance hit away from direct DBMS access. With such an API (and direct access for file open/read/write, etc) just about any language can be implemented inside the box, again with no help from the DBMS provider(s). I'm guessing we could count on two hands how many people might actually be intensely interested in any of this. T As an end-user developer, you probably won't find much interest. There's too much to do with the core business code as it is. Would it make life easier for the few solutions developers who actually might want it? I know I've wanted similar gut hooks for my own oddball projects but I have always found a way to make things happen without it. Just because we're clever enough to connect points A and B, though, doesn't mean we should simply accept that the steps involved always be convoluted and the process numbingly inefficient. Do the DBMS vendors not care about making the solutions-providing developer's lives easier? Who really sells their product? How many forward-thinking developers have left MV because these should-haves never have existed. How many migrations have happened due to a small subset of those must-haves have popped up in another flavor? GlenB ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users How many companies sole source of income is from innovation and investment from 2-3 decades and 6 owners ago? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/4/2011 11:10 PM, DavidJMurray (mvdbs.com) wrote: Yes, it is possible to use intercall with Python using the ctypes module: http://mvdbs.com/2010/07/05/python-to-intercall/ We previously attempted to use SWIG to get python to call InterCall, but ran into issues with python (64 bit) and intercall (32 bit). We didn't want to completely reinstall python from source and compile as 32 bit. Does the ctypes module in python allow calling 32-bit intercall libs from a 64-bit install of python? -- Jeff Butera Hampshire College jbut...@hampshire.edu 413-559-5556 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Thank You David! Nice blog. On Fri, Feb 4, 2011 at 11:10 PM, DavidJMurray (mvdbs.com) nab...@mvdbs.com wrote: Yes, it is possible to use intercall with Python using the ctypes module: http://mvdbs.com/2010/07/05/python-to-intercall/ Cheers, djm slestak wrote: This might be a way to call the Intercall routines. http://docs.python.org/extending/extending.html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Re%3A-UUID--was-Data-in-Dict--tp30772851p30849962.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Thanks for you kind comments. Remember to comment any article that you find of value. Cheers, djm slestak wrote: Thank You David! Nice blog. On Fri, Feb 4, 2011 at 11:10 PM, DavidJMurray (mvdbs.com) nab...@mvdbs.com wrote: Yes, it is possible to use intercall with Python using the ctypes module: http://mvdbs.com/2010/07/05/python-to-intercall/ Cheers, djm slestak wrote: This might be a way to call the Intercall routines. http://docs.python.org/extending/extending.html - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Re%3A-UUID--was-Data-in-Dict--tp30772851p30854045.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Jeff, I have not tried ctypes etc on a 64-bit platform, but if SWIG had issues, then I would not be surprised if ctypes also had some issues. Is there not a 64-bit intercall with 64-bit UniVerse? djm Jeffrey Butera wrote: On 2/4/2011 11:10 PM, DavidJMurray (mvdbs.com) wrote: Yes, it is possible to use intercall with Python using the ctypes module: http://mvdbs.com/2010/07/05/python-to-intercall/ We previously attempted to use SWIG to get python to call InterCall, but ran into issues with python (64 bit) and intercall (32 bit). We didn't want to completely reinstall python from source and compile as 32 bit. Does the ctypes module in python allow calling 32-bit intercall libs from a 64-bit install of python? - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Re%3A-UUID--was-Data-in-Dict--tp30772851p30854198.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 02/05/2011 05:18 PM, DavidJMurray (mvdbs.com) wrote: Thanks for you kind comments. Remember to comment any article that you find of value. Cheers, djm slestak wrote: Thank You David! Nice blog. On Fri, Feb 4, 2011 at 11:10 PM, DavidJMurray (mvdbs.com) nab...@mvdbs.com wrote: Yes, it is possible to use intercall with Python using the ctypes module: http://mvdbs.com/2010/07/05/python-to-intercall/ Cheers, djm slestak wrote: This might be a way to call the Intercall routines. http://docs.python.org/extending/extending.html - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com I attempted to and got an error regarding the wordpress captcha. Not that I entered it incorrectly, just a wp malfunction. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Fixed. Thanks for that. djm slestak wrote: http://mvdbs.com http://mvdbs.com I attempted to and got an error regarding the wordpress captcha. Not that I entered it incorrectly, just a wp malfunction. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Re%3A-UUID--was-Data-in-Dict--tp30772851p30854926.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/4/2011 2:18 PM, fft2...@aol.com wrote: I have to disagree with the claim that none of the above interfaces exist. I'm currently in conversation with someone who has achieved connectivity from PerlPHPD3 in order to have a type of web store. I'm going to be looking at this to make the mods necessary to make it Perl PHPUniverse. It uses some kind of class, I haven't seen the code yet, but why would this not be one of the above interfaces? Or perhaps I'm just not understanding what you mean. As far as dinosaurs. I think, because I'm starting to work on the history of Pick articles, that people are finding me because I'm dragging out of the closet such things as UPDATE :) Which by the way, prior to this new prospect, I had not even *heard* of for the last ten years, let alone seen. W ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Most of this discussion is about client side connectivity. What I would love to see is a replacement for UniBASIC. Server side language bindings are what interest me. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
In a message dated 2/4/2011 11:23:36 AM Pacific Standard Time, slestak...@gmail.com writes: Most of this discussion is about client side connectivity. What I would love to see is a replacement for UniBASIC. Server side language bindings are what interest me. Of course you can do this. Which of your clients do you think would be willing to pay me to develop all the subroutines in PHP ? You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. How do you even address the database without going through the low-level read write core ? You have to scan the file structure, with a knowledge of groups and delimiters and link space and then be able to extract the records, and put them back... by frame. and append when necessary and relink. That's a lot of code. But you can certainly create the routines in PHP that do the file manangement with the UniBASIC relegated to just the middle level of read-write processing and nothing else, and then start building your PHP routines on *top* of these. W ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/4/2011 2:29 PM, fft2...@aol.com wrote: In a message dated 2/4/2011 11:23:36 AM Pacific Standard Time, slestak...@gmail.com writes: Most of this discussion is about client side connectivity. What I would love to see is a replacement for UniBASIC. Server side language bindings are what interest me. Of course you can do this. Which of your clients do you think would be willing to pay me to develop all the subroutines in PHP ? You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. How do you even address the database without going through the low-level read write core ? You have to scan the file structure, with a knowledge of groups and delimiters and link space and then be able to extract the records, and put them back... by frame. and append when necessary and relink. That's a lot of code. But you can certainly create the routines in PHP that do the file manangement with the UniBASIC relegated to just the middle level of read-write processing and nothing else, and then start building your PHP routines on *top* of these. W ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users If I was in Rockets shoes, I would reimplement Unibasic in python, or maybe a jvm language, like Clojure is LISP for the jvm. All the existing code would still run, but you would gain all of the goodness of the last 40 years of work. Doing as a JVM language is probably the safest move, and wouldnt be that difficult. Think, interopability between java, scala, jython. It would really breathe new life into the product. I think what I would call this is refactoring the DML. Leave the verbs there, but reimplement them. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
On 2/4/2011 2:29 PM, fft2...@aol.com wrote: Of course you can do this. Which of your clients do you think would be willing to pay me to develop all the subroutines in PHP ? This will never be done on an hourly basis for a client. Something like this will be done probably by an inhouse team member scratching their own itch. You will never be able to go completely away from UniBASIC while keeping a U2 database. I don't think that's possible. How do you even address the database without going through the low-level read write core ? You have to scan the file structure, with a knowledge of groups and delimiters and link space and then be able to extract the records, and put them back... by frame. and append when necessary and relink. That's a lot of code. No, Intercall. If I could program c, I would already have my python DML. But you can certainly create the routines in PHP that do the file manangement with the UniBASIC relegated to just the middle level of read-write processing and nothing else, and then start building your PHP routines on *top* of these. W er.u2ug.org/mailman/listinfo/u2-users Along my earlier line of thought, the eclipse love they have and the java they have already invested in with redback will just get better. E ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
If I was not already stacked up to the gills, I would be working on this right now. I have a couple of false starts, and have reached out to a few c programmers. One day... ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
This might be a way to call the Intercall routines. http://docs.python.org/extending/extending.html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
We were just discussing something similar on the PHP Meetup list. Lots of people have lots of ideas. The ideas aren't what turn a 0 company into a ten million dollar one. I have lots of ideas also, as does every programmer or engineer. An idea, a vision, a plan, go so far. If you don't have the power to make it appear, you don't have anything. And even the product won't move if you don't have the salesforce to push it along, which means you need some excitement building among the chorus. The only chorus I hear today is the web store chorus which seems to drown out everyone else :) ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] A new DML?
Yes, it is possible to use intercall with Python using the ctypes module: http://mvdbs.com/2010/07/05/python-to-intercall/ Cheers, djm slestak wrote: This might be a way to call the Intercall routines. http://docs.python.org/extending/extending.html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - Learn and Do Excel and Share http://mvdbs.com http://mvdbs.com -- View this message in context: http://old.nabble.com/Re%3A-UUID--was-Data-in-Dict--tp30772851p30849962.html Sent from the U2 - Users mailing list archive at Nabble.com. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
