On 25 October 2013 13:28, John Gilmore wrote:
> Apart from its vulnerability to security-breaching abuses and the fact
> that it must often be copied to be operated upon, another major defect
> of ther nul-terminated string is that it may not contain a nul.
>
> I do not regard the nul-terminated s
You can also generate code on the first reference in dynamic memory and use
that generated code to do the compares. Just build a little subroutine at run
time and branch to that subroutine to do the actual compares, etc. Several
software products do this.
Lloyd
>
On 2013-10-24 09:35, David Cole wrote:
>
> The reason that this useful is that this quirk can be exploited to
> create, for example, a MAX or MIN function that is evaluated at
> assembly time. (Maybe this has changed, but the last time I looked,
> the Assembler did not offer native MAX and MIN func
These are issues of taste.
The text of a single mote may be 1024 characters in length.
Historically they were kept terse to save storage. This rationale for
brevity is no more, I therefore try to provide very full information
in error mnotes, including any contextual information that is likely
t
On 25 October 2013 17:59, John Gilmore wrote:
> Rob's macro FOOBAR is easy to improve, as in
>
I don't disagree yet, but what's the improvement? It's a lot more code
(though still less than what I inherited) and I agree the mnote is more
verbose. But does it serve a purpose? Maybe I've tried to
Apart from its vulnerability to security-breaching abuses and the fact
that it must often be copied to be operated upon, another major defect
of ther nul-terminated string is that it may not contain a nul.
I do not regard the nul-terminated string as a serious, i.e.,
non-frivolous data type. Oddl
On 2013-10-25, at 10:11, John Gilmore wrote:
>
> Moreover, nuls are unproblematic; they are invariant, the
> same in ASCII, EBCDIC, . . .
>
Mostly true. But don't overlook the curse of the null-terminated
string.
-- gil
I will be out of the office on Monday and Tuesday the 28th & 29th of October,
returning to work on Wednesday 30th.
I will have no access to email / phone during this time.
For all urgent project/maintenance related questions or issues, please send a
mail to ANI - BOB-Visuals Support. For all ot
As I made clear in an earlier post, it is my habit to pad out table
elements with nuls, instances of x'00', to make all of their lengths
equal.
This operation is trivial in the macro language, but in response to
some off-line questions I note that either of
|&nulchar setc BYTE(x'00')
or
|&nulch
Rob's macro FOOBAR is easy to improve, as in
| macro
| FOOBAR &a=,&b=&c=
| more than one keyword-pasrameter value supplied?
|
|&a_in setb(t'&a ne 'O')--&a value supplied?
|&b_in setb(t'&b ne 'O')--&b value supplied?
|&c_in setb
I by no means meant to criticize the technique you described. On the contrary,
I find it cool and refreshing. I like when it makes me think to determine what
it is doing and how.
OTOH you are perfectly correct that a 1000-line if clause is just as (or maybe
more) hard to decipher.
Managers a
On 2013-10-24, at 00:41, Rob van der Heij wrote:
> On 24 October 2013 02:42, Tony Harminc wrote:
>
>> That's a very APLish thing to do.
>>
I'm sorry.
> No doubt a matter of style and experience, but I find if/then/else hard to
> follow when reading. Especially when ident does not match the nesti
On 2013-10-23, at 19:33, robin wrote:
> From: "Paul Gilmartin"
> Sent: Thursday, October 24, 2013 11:51 AM
>
>> On 2013-10-23 18:36, robin wrote:
>>>
>>> And anyway, how do you think that J > K is computed?
>>>
>>> The comparison is performed by subtracting K from J
>>> (without changing either J
Maybe that explains the disconnect.
I am saying that all ROWs must be of equal length. Each row may contain
one or more fields. I did not say that the individual data fields in the
row must be fixed length.
In other words, each table occurance must be the same length.
Tony Thigpen
-Origina
OK you two, Tony and Robin, you are looking at the same thing from two
directions, I think.
Robin is saying each element, or structure, or entry, is the same length. The
data stored in the element is variable in length.
So, Robin is right that you can binary search a table with variable length
On 24 October 2013 16:25, Farley, Peter x23353
wrote:
Wow. I have occasionally been accused of using obscure, "unmaintainable"
> code in the name of efficiency, but that "gubbins" example and Rob's
> default parameter assignment parse make me look positively conservative.
>
Oh dear, I need to de
As I don't know PL/I or PLX and this is the Assembler list, let's talk
assembler.
You stated that your code produced a binary search against a table where
each row was variable length.
I said binary search can't work on such a table.
So, produce the code in assembler.
Tony Thigpen
-Origin
From: "Tony Thigpen"
Sent: Friday, October 25, 2013 10:05 PM
Convert your PLX code to assembler and you will see that you are binary
searching a pointer table that has fixed length entries.
In PL/I , each string value (= each element of an array) occupies exactly the
same storage.
Convert your PLX code to assembler and you will see that you are binary
searching a pointer table that has fixed length entries.
Tony Thigpen
-Original Message -
From: robin
Sent: 10/25/2013 04:52 AM
From: "Tony Thigpen"
Sent: Friday, October 25, 2013 12:16 PM
> In XPL, each strin
From: "Tony Thigpen"
Sent: Friday, October 25, 2013 12:16 PM
> In XPL, each string is accessed via descriptor that contains in a single
> word
> the memory address and the length.
Your code is doing a binary search of the FIXED length POINTER table.
No it's not. The code re-posted for you i
20 matches
Mail list logo
