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 thr
In view of posts in this thread about GT.M and free software, a few
clarifications may be in order.
Apropos the discussion on free software, the intention with GT.M on x86
GNU/Linux is to provide software to a user community that is Free as in
free speech, as opposed to free as in free beer. That
Greg Woodhouse wrote:
>--- 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
>>
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
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 (virtua
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 complie
> 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 b
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 outpu
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?
Rube
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.
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:
>
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 d
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
-
> 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
-
> 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 embedded into th
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 whi
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 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 and other things I'd rather do
>> with the time I do have. No doubt we can all say essentially
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
>
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
> 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
>
> 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.N
> 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 limit
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
f
--- 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 b
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
> > > th
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 off
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
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 t
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 limit
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.
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 "
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 image
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.
--- 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
> -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
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 a
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
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 he
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
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]> wrot
> He is actually trying to write something cross-platform
> ultimately, so you can both pull in your horns.
Jews don't have horns (anymore)
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San
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 wha
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
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 lo
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
r
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.
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 Toppenber
> 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 mus
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 (a
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
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
> > capab
age-
> From: [EMAIL 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 wi
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 to
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
32-bit characters (probably the next level of
technology).
Best wishes; Chris
- Original Message -
From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 21, 2005 5:24 PM
Subject: Re: [Hardhats-members] more M read question
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 -040
David Sommers, 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,
IELDDATA), 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
) 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: [Hardhat
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
> implement
PROTECTED]>
Sent: Sunday, August 21, 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 usi
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 doe
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 big
64 matches
Mail list logo