I certainly do not.
--- K.S. Bhaskar [EMAIL PROTECTED] wrote:
If anyone ever feels that I get too
commercial, please feel free to castigate me.
Thank you very much.
Regards
-- Bhaskar
P.S. Kevin, did you ever get your IO working? I think that was what
started the thread.
===
Most MUMPS implementations have no problem with binary data. It's old utilities
that are
oriented to text-only data that might have a problem with it. GT.M, for
instance is quite
capable of uploading and downloading binary data, such as images, just fine. It
can also
easily hand off that task
PROTECTED] [mailto:hardhats-
[EMAIL PROTECTED] On Behalf Of Jim Self
Sent: Monday, August 22, 2005 3:13 AM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] more M read questions
Most MUMPS implementations have no problem with binary data. It's old
utilities
Off hand, I don't know, but members of this list do seem to have a
tendency to plug GT.M (presumably because it is open source).
Personally, I think we'd all benefit from a little more vendor
neutrality.
--- Thurman Pedigo [EMAIL PROTECTED] wrote:
. GT.M, for
instance is quite
capable of
On Mon, 2005-08-22 at 11:18, Greg Woodhouse wrote:
Off hand, I don't know, but members of this list do seem to have a
tendency to plug GT.M (presumably because it is open source).
Personally, I think we'd all benefit from a little more vendor
neutrality.
Good Morning!
I don't know what
What $P change is that?
In any case, I agree with Kevin that I/O in MUMPS could be simplified.
That being said, this is a stumbling block in any language becaue the
user needs both the capability of reading (up to) a fixed number of
bytes and scanning the input stream for complete lines of text
In the latter case,
there is the problem that M programmers have a propensity for using
sentinel values like ^ to delimit data items, but the first problem
is much more serious.
The only sure fire way to get data moved somewhere is with something
like fread or fwrite. You must know
I thought that was part of the purpose of $P change in the GTM code, to get it
to recognize the TCP processes and not cut them off when something that would
otherwise be recognized as a control character was sent. Can you leverage
that somehow?
On Sunday 21 August 2005 09:46 am, Kevin
First of all, this is not a WorldVistA list, this is Hardhats. If
WorldVistA chooses to focus entirely on GT.M that is their choice, but
not everyone running (or interested in running) VistA will use GT.M,
and the intent of this list is to focus on VistA infrastructure
regardless of the platform.
Right (no pun intended).
The problem, of course, is that a # read in MUMPS doesn't necessarily
behave like an fread. If it did, life would be much simpler. Or would
it? There is still the problem ot text I/O, and unlike most other
languages, MUMPS provides no standard mechanism of for linking to
Guys, Kevin happens to be trying to code this at the moment and he is running
GTM on his server. He is actually trying to write something cross-platform
ultimately, so you can both pull in your horns. We are looking for a
scanning solution that will work for everyone, and Kevin is putting a
On Mon, 2005-08-22 at 12:04, Greg Woodhouse wrote:
First of all, this is not a WorldVistA list, this is Hardhats. If
WorldVistA chooses to focus entirely on GT.M that is their choice, but
not everyone running (or interested in running) VistA will use GT.M,
and the intent of this list is to
On Mon, 2005-08-22 at 12:15, In addition,
languages need to provide support for binary files, pipes and FIFOs,
TCP channels and the like. MUMPS is very (7-bit) text-centric,
essentially by design.
Writing an encoding scheme should be fairly straight forward. 7 bit to
8 bit is exactly what
I'm very familiar with electronic mail. I'll have to check to see if
it's still there, but I may be responsible for a paltry single phrase
in RFC 2821 (though I'd like to think that my participation in the WG
mailing lists amounted to a bit more than that).
--- Ruben Safir [EMAIL PROTECTED]
On Mon, 2005-08-22 at 12:41, Greg Woodhouse wrote:
I'm very familiar with electronic mail. I'll have to check to see if
it's still there, but I may be responsible for a paltry single phrase
in RFC 2821 (though I'd like to think that my participation in the WG
mailing lists amounted to a bit
Right after you tell me about the bitwise operators in MUMPS!
Actually, though you can't do bit arithmetic in MUMPS, you do have $A()
and $C() so its quite possible to perform ordinary arithmetic on
character values, so something like base64 shouldn't be too hard.
Fileman even provides a basic
Oops. that didn't wor'k. I'm using a web interface and the 94's were
translated to ^. I wa wrong on two counts: the encoding is decimal,
not hexadecimal, and the encoding used is the standard one for numeric
entities in XML/HTML (meaning, BTW, that the name of the call is less
of a misnomer than I
Greg Woodhouse wrote:
Off hand, I don't know, but members of this list do seem to have a
tendency to plug GT.M (presumably because it is open source).
Personally, I think we'd all benefit from a little more vendor
neutrality.
I am not a vendor and neither is GT.M. I mention GT.M (and Linux and
-Original Message-
From: [EMAIL PROTECTED] [mailto:hardhats-
[EMAIL PROTECTED] On Behalf Of Ruben Safir
Sent: Monday, August 22, 2005 9:53 AM
To: hardhats-members@lists.sourceforge.net
Subject: RE: [Hardhats-members] more M read questions
I can't speak for others, but I always do
--- Jim Self [EMAIL PROTECTED] wrote:
Greg Woodhouse wrote:
Off hand, I don't know, but members of this list do seem to have a
tendency to plug GT.M (presumably because it is open source).
Personally, I think we'd all benefit from a little more vendor
neutrality.
I am not a vendor and
On Mon, 2005-08-22 at 14:26 -0700, Greg Woodhouse wrote:
I'm less impressed by this argument. First of all, totally free is
an
illusion. You may not spend money on licensing fees, but if it takes
you 10 or 100 or 1,000 hours of work to install and configure the
system, that is a cost.
That's
Normal email is text based. In mime encoding, it handles binary files as
attachments by
surrounding them with a string of ASCII characters guaranteed not to be
included in the
content. This is a standard feature of web browsers used to upload HTML forms
that can
include binary data such as
On Mon, 2005-08-22 at 14:26 -0700, Greg Woodhouse wrote:
Open source may be a
good thing (and I think it is), but is it being touted because it's
the
right way to do things or because it's the cheapest?
I don't know what Open Source is exactly, but in the case of Free
Software, its the right
On Mon, 2005-08-22 at 14:26 -0700, Greg Woodhouse wrote:
I've actually
thought about inquiring into whether porting MUMPS_V1 to OS X might be
an option, but I also have limited time and other things I'd rather do
with the time I do have. No doubt we can all say essentially the same
thing.
Maybe not, but it's still not at the top of my priorities list.
--- Ruben Safir [EMAIL PROTECTED] wrote:
On Mon, 2005-08-22 at 14:26 -0700, Greg Woodhouse wrote:
I've actually
thought about inquiring into whether porting MUMPS_V1 to OS X might
be
an option, but I also have limited time
That's one perspective, but to others it might be a business decision.
In the case of VistA, a hypothetical health care provider may opt for
an open source solution because it believes that they money saved in
licensing fees will not be offset, say, by increased support costs.
Now, it may well be
Gregory Woodhouse [EMAIL PROTECTED]
My point of view is that programmers should not have
to do extra work or rely on libraries or applications over and above
the basic language environment to perform basic I/O tasks. In addition,
languages need to provide support for binary files, pipes and
On Mon, 2005-08-22 at 18:10, Greg Woodhouse wrote:
That's one perspective, but to others it might be a business decision.
In the case of VistA, a hypothetical health care provider may opt for
an open source solution because it believes that they money saved in
licensing fees will not be
On Mon, 2005-08-22 at 18:00, Greg Woodhouse wrote:
Maybe not, but it's still not at the top of my priorities list.
That's COMPLETELY understandable.
Ruben
--- Ruben Safir [EMAIL PROTECTED] wrote:
On Mon, 2005-08-22 at 14:26 -0700, Greg Woodhouse wrote:
I've actually
thought about
--- Jim Self [EMAIL PROTECTED] wrote:
Gregory Woodhouse [EMAIL PROTECTED]
You keep making noises like you want to redesign the MUMPS language.
Perhaps you should
get involved with the development of GT.M or MUMPS_V1 or Kevin
O'Kane's MUMPS, or even
better with all three, and bring them
From: "Ruben
Safir" Monday, August 22, 2005 6:03 PM I don't know what Open Source
is exactly, but in the case of Free Software, its the "right" way to do
things. Its also usually the least expensive way as well, but that
is just a side affect of it being a Free Software program. The
freer
You have missed a very critical difference in the concept of Open
Source,
that is that the source code is available. Free software, the stuff
that is
given away, does not always incorporate the source code. The fact
that I
have access to the source code permits me to know the limitations
Lastly, what is meant by the statement: The freer things are, in most
things, the more money you make and the less you pay for a unit. Who
is
referenced by the you.
That would be you in the perfect sense.
Ruben
---
SF.Net email is
There are a number of reasons I'm not especially interested in getting
involved with GT.M development right now. I have (seriously) considered
it, but I have seen little interest expressed on this list in
addressing the types of issues I've attempted to call attention to, and
supporting the
Fascinating. A language with tensed personal pronouns.
--- Ruben Safir [EMAIL PROTECTED] wrote:
That would be you in the perfect sense.
Ruben
===
Gregory Woodhouse [EMAIL PROTECTED]
Design quality doesn't ensure success, but design failure can ensure failure.
--Kent Beck
From: Ruben Safir Monday, August 22, 2005 6:50 PM
I believe your confusing Free Software with the marketing speech created
by Bruce Perens.
It's Free Software, like in Free Market, and it has a specific
definition which is detailed here
http://www.gnu.org/philosophy/free-sw.html
Yes, of
From: Ruben Safir Monday, August 22, 2005 6:52 PM
Lastly, what is meant by the statement: The freer things are, in most
things, the more money you make and the less you pay for a unit. Who
is
referenced by the you.
That would be you in the perfect sense.
Ruben
This is
On Mon, 2005-08-22 at 18:54, Michael D. Weisner wrote:
From: Ruben Safir Monday, August 22, 2005 6:50 PM
I believe your confusing Free Software with the marketing speech created
by Bruce Perens.
It's Free Software, like in Free Market, and it has a specific
definition which is
This is perfectly ridiculous. One is either buying or selling, not both.
It's both and everyone. Buyers, sellers, and even people who live on
small islands in the pacific. Its You in the perfect sense.
If you want to discuss this more, email me off list.
Thanks
Ruben
On Mon, 2005-08-22 at 18:48, Greg Woodhouse wrote:
Fascinating. A language with tensed personal pronouns.
I think it is called perfect because it refers to group of people, each
one individually, and at any time.
It's more common in Hebrew.
Ruben
No, the issue is that it's necessary to compile MUMPS (not C). In
principle, there's no reason why it can't be done.
--- Ruben Safir [EMAIL PROTECTED] wrote:
Unlike GT.M, it does not generate machine language in
compiling MUMPS source routines so I would expect no special
surprizes due to
So, you're serious? That really is interesting. I have read that
Japanese has a group of adjectives that can exhibit tense, but I did
not know that pronouns in Hebrew could exhibit aspect like this.
--- Ruben Safir [EMAIL PROTECTED] wrote:
On Mon, 2005-08-22 at 18:48, Greg Woodhouse wrote:
When God talks, everyone listens ;)
Ruben
On Mon, 2005-08-22 at 19:20, Greg Woodhouse wrote:
So, you're serious? That really is interesting. I have read that
Japanese has a group of adjectives that can exhibit tense, but I did
not know that pronouns in Hebrew could exhibit aspect like this.
On Mon, 2005-08-22 at 19:14, Greg Woodhouse wrote:
No, the issue is that it's necessary to compile MUMPS (not C). In
principle, there's no reason why it can't be done.
I understand that. (or maybe I don't) But why can't GT.M compile to
create binary RISK instructions for mumps with gcc?
Ruben
Ruben wrote:
Unlike GT.M, it does not generate machine language in
compiling MUMPS source routines so I would expect no special surprizes due
to the shift
from X86 on FreeBSD to PPC on OS/X.
Why can't the complier generate the correct machine code for the RISC ?
Is binary outputs embedded
Greg said:
Unlike GT.M, it does not generate machine language in
compiling MUMPS source routines so I would expect no special surprizes due
to the shift
from X86 on FreeBSD to PPC on OS/X.
Why can't the complier generate the correct machine code for the RISK ?
Is binary outputs
On Mon, 2005-08-22 at 16:58 -0700, Jim Self wrote:
Ruben wrote:
Unlike GT.M, it does not generate machine language in
compiling MUMPS source routines so I would expect no special surprizes due
to the shift
from X86 on FreeBSD to PPC on OS/X.
Why can't the complier generate the
Actually, the problems are a lot more severe than the issue of 32 vs.
64 bit architectures. MUMPS is very free in allowing execution of
strings built at runtime (much like LISP). Think about how you might
go about compiling LISP to native code without relying on any sort of
abstract
On Mon, 2005-08-22 at 23:49, Gregory Woodhouse wrote:
Actually, the problems are a lot more severe than the issue of 32 vs.
64 bit architectures. MUMPS is very free in allowing execution of
strings built at runtime (much like LISP). Think about how you might
go about compiling LISP to
Kevin;
There is only a single data-type in MUMPS, strings. What you are doing
is a fixed length buffer read of characters (real characters or binary
data). You are opening up a big bag of issues which the MDC argued over for
decades. If you are talking about binary, are you talking about
Kevin,
You are on the right track. Increasing the number of characters per READ is by
far the most significant thing you can do to speed up your routine. Reading
one character at a time using a star-Read is very slow. Each M implementation
has a way to do binary reads -- ie, a read which
, 2005 12:52 PM
Subject: Re: [Hardhats-members] more M read questions
Kevin,
You are on the right track. Increasing the number of characters per READ is
by far the most significant thing you can do to speed up your routine.
Reading one character at a time using a star-Read is very slow. Each M
On Sun, 2005-08-21 at 15:13 -0400, smcphelan wrote:
Here, here. Chris also stated this. ANSI standard M is not really designed
to handle binary data. This is one reason Intersystems added extensions (if
you wish to call it that). But then you are bound to a specific M vendor's
) characters per word (Univac
FIELDDATA), or 10 6-bit characters/word, but each of these are mapping
systems for characters.
- Original Message -
From: Ruben Safir [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, August 21, 2005 12:46 PM
Subject: Re: [Hardhats-members] more M read
of these are mapping
systems for characters.
- Original Message -
From: Ruben Safir [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, August 21, 2005 12:46 PM
Subject: Re: [Hardhats-members] more M read questions
On Sun, 2005-08-21 at 15:13 -0400, smcphelan wrote:
Here, here
, Architect | Dialog Medical
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ruben
Safir
Sent: Sunday, August 21, 2005 3:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [Hardhats-members] more M read questions
On Sun, 2005-08-21 at 15:13 -0400, smcphelan wrote:
Here
PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, August 21, 2005 12:46 PM
Subject: Re: [Hardhats-members] more M read questions
On Sun, 2005-08-21 at 15:13 -0400, smcphelan wrote:
Here, here. Chris also stated this. ANSI standard M is not really
designed
to handle binary data
The key word (not the keyword) here is encoded. Fileman actually
provides utilities for hexadecimal encoding that I've found useful on
more than one occasion. There are really two issues here: whether the
M implementation can handle binary data (not necessarily), and
whether applications
58 matches
Mail list logo
