[30587] in Perl-Users-Digest
Perl-Users Digest, Issue: 1830 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 1 06:09:41 2008
Date: Mon, 1 Sep 2008 03:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 1 Sep 2008 Volume: 11 Number: 1830
Today's topics:
is there a GUI for Perl to display large tree structure <woland99@gmail.com>
Re: is there a GUI for Perl to display large tree struc xhoster@gmail.com
logic error in group <enough.is@enough.invalid>
Re: logic error in poster <cwilbur@chromatico.net>
Re: logic error in poster <1usa@llenroc.ude.invalid>
Re: Multiple processes and tie'd files xhoster@gmail.com
Re: Multiple processes and tie'd files xhoster@gmail.com
Re: Multiple processes and tie'd files <alex@digriz.org.uk>
new CPAN modules on Mon Sep 1 2008 (Randal Schwartz)
Re: The Importance of Terminology's Quality (Robert Maas, http://tinyurl.com/uh3t)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 31 Aug 2008 16:41:34 -0700 (PDT)
From: Woland99 <woland99@gmail.com>
Subject: is there a GUI for Perl to display large tree structures ?
Message-Id: <8db4cee7-7bae-4004-8e63-bd36e5e8315d@d77g2000hsb.googlegroups.com>
I am looking for a way to display large tree structure - 60-70,000
nodes
resulting from parsing source code for an OO language. I tried Tk
widget
in the best but it would choke. I know it can be done in VB but I was
curious
if there are any GUI toolkits in Perl capable of doing it.
At the beginning I would like the tree nodes to be all collapsed and I
would
like to be able to do regexp searh for a node that would result in
expansion
of intermediate nodes. Essentially I need a source code browser for
a proprietary (Java like) language.
TIA for any pointers/info/references,
JT
------------------------------
Date: 31 Aug 2008 23:48:05 GMT
From: xhoster@gmail.com
Subject: Re: is there a GUI for Perl to display large tree structures ?
Message-Id: <20080831194808.356$H6@newsreader.com>
Woland99 <woland99@gmail.com> wrote:
> I am looking for a way to display large tree structure - 60-70,000
> nodes
> resulting from parsing source code for an OO language. I tried Tk
> widget
> in the best but it would choke. I know it can be done in VB but I was
> curious
> if there are any GUI toolkits in Perl capable of doing it.
> At the beginning I would like the tree nodes to be all collapsed and I
> would
> like to be able to do regexp searh for a node that would result in
> expansion
> of intermediate nodes.
I don't know of any. It doesn't seem like the kind of thing I'd expect
Perl to be a likely candidate for. For first effort would be to translate
the data to XML and then try using various XML viewing tools to see of one
does what you want. I'll the ones I've seen did branch collapsing, but
I don't know of any do searching by regex, but I've never looked.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Sun, 31 Aug 2008 13:37:04 -0700
From: Adam <enough.is@enough.invalid>
Subject: logic error in group
Message-Id: <ThDuk.36195$co7.11655@nlpi066.nbdc.sbc.com>
I am writing this one last post because I feel this group as truly
gotten to the point that one cannot express their views without certain
people, who feel they are above everyone else here changing what you say
or down right lying in order to bury any argument against something they
believe strongly, and demonstrate a complete unwillingness to to debate
on any real civil and/or rational level.
Many of you did this with me in the "CLPM - a help group" thread, and
the same thing has happened in many others, a note worthy thread was the
regarding if it's wrong to write "PERL". Any merit was completely
ignored and what the originally said was changed and words were shoved
into mouths that were never said.
I have no doubt the same people will label this post as just trolling,
instead of admitting any wrong doing as usual. No, we cannot criticize
the so called community core. But what you don't understand is that you
have no real power, despite what you want everyone to believe.
All you have proven is that this group is not worth investing any time
in. Life is to short to waste on people who are "never wrong" and refuse
to defend their points of view with logic and rationality and instead
engage in ways not unlike those formerly in the USSR.
- Adam J. Worrell
It's a shame the type of People we fought to vanquish from
the world during the Cold War have come to rule Usenet.
------------------------------
Date: Sun, 31 Aug 2008 16:42:44 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: logic error in poster
Message-Id: <86y72c7w6z.fsf@mithril.chromatico.net>
>>>>> "A" == Adam <enough.is@enough.invalid> writes:
A> All you have proven is that this group is not worth investing any
A> time in.
Don't let the door hit you in the ass as you (finally!) leave.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Sun, 31 Aug 2008 22:23:26 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: logic error in poster
Message-Id: <Xns9B0BBB10A4BCCasu1cornelledu@127.0.0.1>
Charlton Wilbur <cwilbur@chromatico.net> wrote in
news:86y72c7w6z.fsf@mithril.chromatico.net:
>>>>>> "A" == Adam <enough.is@enough.invalid> writes:
>
> A> All you have proven is that this group is not worth investing any
> A> time in.
>
> Don't let the door hit you in the ass as you (finally!) leave.
Don't be naive, just prepare for his next personality to show up ;-)
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
------------------------------
Date: 31 Aug 2008 21:17:52 GMT
From: xhoster@gmail.com
Subject: Re: Multiple processes and tie'd files
Message-Id: <20080831171754.690$14@newsreader.com>
Alexander Clouter <alex@digriz.org.uk> wrote:
> xhoster@gmail.com wrote:
> > Tuc <tuctboh@gmail.com> wrote:
> >> Hi,
> >>
> >> I'm running into an issue when using a file I've tied, and there
> >> are multiple long term running processes. I first ran into it with
> >> Squid as a redirection program (Never resolved it), and now with
> >> MimeDefang.
> >>
> >> When I tie to a DB_File, if one of the processes or even an
> >> external process updates the file, the persistent processes aren't
> >> seeing the update. I have to stop them and restart them for that to
> >> happen.
> >
> > Have you read the documentation for DB_File?
> >
> The documentation for DB_File has *nothing* to say on this that is
> useful,
I found it's discussion of locking useful.
...
>
> UNIX has this rather nice feature where when a file is open that FD's
> 'view' of the file does not change even if you delete the file or edit
> it.
This is absolutely not true. The FD view does not change on file deletion,
but it absolutely does change on file content edits.
> >
> > Mysql is not a super-collider, it is a very light-weight fly swatter.
> > What you are trying to doing with DB_File is like trying to swat a fly
> > with a pencil sharpener.
> >
> No no no, MySQL is horrible! Putting any network based database into the
> critical loop of a realtime interactive is a bad bad idea.
MySQL doesn't have to be "network based". You can run it on the same
server if you choose to. And if you are willing to compromise by using
stale data for a minimum amount of time, you can implement that "feature"
in mysql just like you can in DB_File.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 31 Aug 2008 21:51:35 GMT
From: xhoster@gmail.com
Subject: Re: Multiple processes and tie'd files
Message-Id: <20080831175138.252$Z5@newsreader.com>
Tuc <tuctboh@gmail.com> wrote:
> On Aug 31, 12:15 am, xhos...@gmail.com wrote:
> >
> > You might be able to use DB_File, you would just need to untie and
> > retie each time you want to sync. But, if you have multiple concurrent
> > accesses, which you do otherwise the problem wouldn't exist, then you
> > need to do locking as well or your database file will be corrupted.
> >
> > From the DB_File docs, it sound like Tie::DB_LockFile might be just
> > what you need, except that no module by that name actually seems to
> > exist on CPAN or anywhere else I can find.
> >
> I was hoping not to have to incur the expense of untie/tie every
> time.
> But it seems like for a quick/easy solution, that'll be it.
If you are willing to use stale data for up to, say, 15 seconds, then
you could delay for at least that long between untie/tie operations.
But if you do, you need to be careful not to get corrupted input. One way
is to copy and use the copy for those >=15 seconds (like Tie::DB_Lock,
which actually does seem to exist, does). The other is to make sure
the write process doesn't overwrite the DB file, but rather replaces it
by moving a different inode to that same name.
> The long running processes are read only. An external program
> from it will
> be the only one with write/update capability. (Actually, when the file
> gets rebuilt
> it gets REBUILT. Basically looks like it re-writes the whole file from
> scratch.
> No "delete" of records, just "open, insert*X, close".
If this is done "in place", then locking is probably still necessary. If
one of the read-only scripts reads the file while it is in the process of
being re-built, it could get very confused. Perhaps this is rare
enough/harmless enough that you are willing to take the risk.
If it is done by creating a new DB_File, then mv-ing the new file to
replace the old one, then it should probably be safe on unix-ish
filesystems.
> >
> > > So what do you suggest to be able to do this? Just "open,
> > > while, close" a text file?
> >
> > I don't see how this would get the job done. There would have to be a
> > "print" in there someplace, or else the whole premise of your question
> > would be void. And then there would have to be locking, or corruption
> > would happen.
> >
>
> Be reasonable, you know there was more to it than what was said, it
> was
> just a way to convey the idea of always opening a file,
Optimization and concurrency are both fiddly businesses. Trying to do them
requires an "unreasonable" level of precision.
>
> #previous programming above here, including shbang to perl interpreter
> undef $value;
>
> open (MAILID,"</etc/mail/mailid");
> while (<MAILID>) {
> ($key,$value)=split(/\t/,$_);
> if ($key =~ /^$lookingfor$/) {
> last;
> }
> }
> close (MAILID);
>
> if ($value)
> {
> #rest of processing here
> }
If the file is small (<100), doing this each time might be faster than
untie and retie each time. But other than that, this is morally equivalent
to using DB_File. The same issues of locking, isolation, concurrency,
corruption, etc. still apply.
> > If this other program doesn't do locking and can't be made to do it
> > in a way compatible with your program, then you are already playing
> > with fire by having them touch the same DB_File file.
> >
> sendmail only uses the file read only too. I do know it opens the
> file every
> email that comes through though.
Since it is read-only, it won't cause corruption in the disk file. But
it can still get corrupted itself if it reads the file while the other
process is writing it. This is probably an unlikely event, but if you
process a lot of email it will happen eventually. Whether the occasional
weirdness is tolerable to you or not I don't know.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 1 Sep 2008 10:05:37 +0100
From: Alexander Clouter <alex@digriz.org.uk>
Subject: Re: Multiple processes and tie'd files
Message-Id: <1snso5-mfv.ln1@woodchuck.wormnet.eu>
xhoster@gmail.com wrote:
> Alexander Clouter <alex@digriz.org.uk> wrote:
>> xhoster@gmail.com wrote:
>> > Tuc <tuctboh@gmail.com> wrote:
>> >> Hi,
>> >>
>> >> I'm running into an issue when using a file I've tied, and there
>> >> are multiple long term running processes. I first ran into it with
>> >> Squid as a redirection program (Never resolved it), and now with
>> >> MimeDefang.
>> >>
>> >> When I tie to a DB_File, if one of the processes or even an
>> >> external process updates the file, the persistent processes aren't
>> >> seeing the update. I have to stop them and restart them for that to
>> >> happen.
>> >
>> > Have you read the documentation for DB_File?
>> >
>> The documentation for DB_File has *nothing* to say on this that is
>> useful,
>
> I found it's discussion of locking useful.
>
...locking is for wimps :)
>> UNIX has this rather nice feature where when a file is open that FD's
>> 'view' of the file does not change even if you delete the file or edit
>> it.
>
> This is absolutely not true. The FD view does not change on file deletion,
> but it absolutely does change on file content edits.
>
Okay my boo-boo. The hint to the OP is to make your changes atomic so you
use move an amended copy of your DB file to blat your old DB_File and then
the readers can all cleanly use stat() to check for updates.
Create a replacement next to the currently being used one, with a slightly
different filename, 'db.build' for example. Once cooked 'mv db.build db' and
the whole thing should be nicely atomic.
>> > Mysql is not a super-collider, it is a very light-weight fly swatter.
>> > What you are trying to doing with DB_File is like trying to swat a fly
>> > with a pencil sharpener.
>> >
>> No no no, MySQL is horrible! Putting any network based database into the
>> critical loop of a realtime interactive is a bad bad idea.
>
> MySQL doesn't have to be "network based". You can run it on the same
> server if you choose to. And if you are willing to compromise by using
> stale data for a minimum amount of time, you can implement that "feature"
> in mysql just like you can in DB_File.
>
UNIX sockets are still 'network' sockets...
SQL is *terrible* at realtime interactive applications where latency is very
much noticed. If you have an SQL query *every* time someone makes an HTTP
request you are destined to run into problems.
Cheers
Alex
------------------------------
Date: Mon, 1 Sep 2008 04:42:20 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Mon Sep 1 2008
Message-Id: <K6I2EK.1zwx@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
App-sh2p-0.01
http://search.cpan.org/~clive/App-sh2p-0.01/
Perl program to aid for conversion from UNIX shell to Perl
----
ArchivistTools-0.02-1
http://search.cpan.org/~daleamon/ArchivistTools-0.02-1/
----
B-Utils-0.05_10
http://search.cpan.org/~clkao/B-Utils-0.05_10/
Helper functions for op tree manipulation
----
Bitmask-Data-1.05
http://search.cpan.org/~maros/Bitmask-Data-1.05/
Handle bitmasks in an easy and flexible way
----
CLI-Application-0.02
http://search.cpan.org/~jkramer/CLI-Application-0.02/
(not yet) extensible CLI application framework
----
Catalyst-Helper-AuthDBIC-0.02
http://search.cpan.org/~zarquon/Catalyst-Helper-AuthDBIC-0.02/
(EXPERIMENTAL)
----
CatalystX-ListFramework-Builder-0.33
http://search.cpan.org/~oliver/CatalystX-ListFramework-Builder-0.33/
Instant AJAX web front-end for DBIx::Class, using Catalyst
----
Chart-Clicker-2.06
http://search.cpan.org/~gphat/Chart-Clicker-2.06/
Powerful, extensible charting.
----
Chemistry-Elements-1.06
http://search.cpan.org/~bdfoy/Chemistry-Elements-1.06/
Perl extension for working with Chemical Elements
----
Chemistry-Elements-1.07
http://search.cpan.org/~bdfoy/Chemistry-Elements-1.07/
Perl extension for working with Chemical Elements
----
Config-Extend-MySQL-0.01
http://search.cpan.org/~saper/Config-Extend-MySQL-0.01/
Read MySQL configuration file
----
Crypt-GpgME-0.08
http://search.cpan.org/~flora/Crypt-GpgME-0.08/
Perl interface to libgpgme
----
DB-CouchDB-Schema-0.2.1
http://search.cpan.org/~zaphar/DB-CouchDB-Schema-0.2.1/
A Schema driven CouchDB module
----
DB-CouchDB-Schema-0.2.1_fix_pod
http://search.cpan.org/~zaphar/DB-CouchDB-Schema-0.2.1_fix_pod/
A Schema driven CouchDB module
----
DB-CouchDB-Schema-0.2.1_fix_pod_1
http://search.cpan.org/~zaphar/DB-CouchDB-Schema-0.2.1_fix_pod_1/
A Schema driven CouchDB module
----
DBD-Pg-2.10.1
http://search.cpan.org/~turnstep/DBD-Pg-2.10.1/
PostgreSQL database driver for the DBI module
----
DBD-Pg-2.10.2
http://search.cpan.org/~turnstep/DBD-Pg-2.10.2/
PostgreSQL database driver for the DBI module
----
DBD-Pg-2.10.3
http://search.cpan.org/~turnstep/DBD-Pg-2.10.3/
PostgreSQL database driver for the DBI module
----
DBD-Sybase-1.09
http://search.cpan.org/~mewp/DBD-Sybase-1.09/
Sybase database driver for the DBI module
----
DMAMisc-1.01-2
http://search.cpan.org/~daleamon/DMAMisc-1.01-2/
----
Data-Iterator-Hierarchical-0.04
http://search.cpan.org/~nobull/Data-Iterator-Hierarchical-0.04/
Iterate hierarchically over tabular data
----
Data-Rx-0.001
http://search.cpan.org/~rjbs/Data-Rx-0.001/
perl implementation of Rx schema system
----
DateTime-Format-Natural-0.72_01
http://search.cpan.org/~schubiger/DateTime-Format-Natural-0.72_01/
Create machine readable date/time with natural parsing logic
----
Document-0.03-2
http://search.cpan.org/~daleamon/Document-0.03-2/
----
Env-C-0.07
http://search.cpan.org/~stas/Env-C-0.07/
Get/Set/Unset Environment Variables on the C level
----
FCGI-Spawn-0.13
http://search.cpan.org/~veresc/FCGI-Spawn-0.13/
process manager/application server for FastCGI protocol.
----
Fault-1.01-2
http://search.cpan.org/~daleamon/Fault-1.01-2/
----
FileHash-0.01-3
http://search.cpan.org/~daleamon/FileHash-0.01-3/
----
Games-Risk-0.2.3
http://search.cpan.org/~jquelin/Games-Risk-0.2.3/
classical 'risk' board game
----
Games-Risk-0.2.4
http://search.cpan.org/~jquelin/Games-Risk-0.2.4/
classical 'risk' board game
----
Gtk2-Phat-0.08
http://search.cpan.org/~flora/Gtk2-Phat-0.08/
Perl interface to the Phat widget collection
----
Gtk2-Sexy-0.04
http://search.cpan.org/~flora/Gtk2-Sexy-0.04/
Perl interface to the sexy widget collection
----
HTML-DTD-0.01
http://search.cpan.org/~ashley/HTML-DTD-0.01/
local access to the standard and historical HTML DTDs.
----
HTML-DTD-0.02
http://search.cpan.org/~ashley/HTML-DTD-0.02/
local access to the standard and historical HTML DTDs.
----
HTML-DTD-0.03
http://search.cpan.org/~ashley/HTML-DTD-0.03/
local access to the standard and historical HTML DTDs.
----
HTML-SimpleLinkExtor-1.2
http://search.cpan.org/~bdfoy/HTML-SimpleLinkExtor-1.2/
Extract links from HTML
----
HTML-SimpleLinkExtor-1.21
http://search.cpan.org/~bdfoy/HTML-SimpleLinkExtor-1.21/
Extract links from HTML
----
IO-Interactive-0.0.4
http://search.cpan.org/~bdfoy/IO-Interactive-0.0.4/
Utilities for interactive I/O
----
Mac-OSVersion-0.13
http://search.cpan.org/~bdfoy/Mac-OSVersion-0.13/
Get the Mac OS X system version
----
Mac-OSVersion-0.14
http://search.cpan.org/~bdfoy/Mac-OSVersion-0.14/
Get the Mac OS X system version
----
MacOSX-Alias-0.11
http://search.cpan.org/~bdfoy/MacOSX-Alias-0.11/
Read or create Mac OS X aliases
----
Moose-0.55_04
http://search.cpan.org/~drolsky/Moose-0.55_04/
A postmodern object system for Perl 5
----
MooseX-SemiAffordanceAccessor-0.03
http://search.cpan.org/~drolsky/MooseX-SemiAffordanceAccessor-0.03/
Name your accessors foo() and set_foo()
----
MooseX-StrictConstructor-0.06_01
http://search.cpan.org/~drolsky/MooseX-StrictConstructor-0.06_01/
Make your object constructors blow up on unknown attributes
----
MooseX-StrictConstructor-0.06_02
http://search.cpan.org/~drolsky/MooseX-StrictConstructor-0.06_02/
Make your object constructors blow up on unknown attributes
----
Muldis-D-0.47.0
http://search.cpan.org/~duncand/Muldis-D-0.47.0/
Formal spec of Muldis D relational DBMS lang
----
Muldis-Rosetta-0.11.0
http://search.cpan.org/~duncand/Muldis-Rosetta-0.11.0/
Full-featured truly relational DBMS in Perl
----
Net-SPAMerLookup-0.07
http://search.cpan.org/~lushe/Net-SPAMerLookup-0.07/
Perl module to judge SPAMer.
----
RTx-Calendar-0.06
http://search.cpan.org/~nchuche/RTx-Calendar-0.06/
Calendar for RT due tasks
----
SOAP-Integr8-1.0
http://search.cpan.org/~ayates/SOAP-Integr8-1.0/
SOAP::Lite helper class for Integr8 Web Services @ EBI
----
Scanner-0.02-4
http://search.cpan.org/~daleamon/Scanner-0.02-4/
----
Spreadsheet-Read-0.27
http://search.cpan.org/~hmbrand/Spreadsheet-Read-0.27/
Meta-Wrapper for reading spreadsheet data
----
Template-Plugin-DateTime-0.06001
http://search.cpan.org/~dmaki/Template-Plugin-DateTime-0.06001/
A Template Plugin To Use DateTime Objects
----
Text-Match-FastAlternatives-1.01
http://search.cpan.org/~arc/Text-Match-FastAlternatives-1.01/
efficient search for many strings
----
WWW-Discogs-0.05
http://search.cpan.org/~leedo/WWW-Discogs-0.05/
get music related information and images
----
Waft-0.99_01
http://search.cpan.org/~tamashiro/Waft-0.99_01/
A simple web application framework
----
WebService-OnlineJudge-0.01
http://search.cpan.org/~garu/WebService-OnlineJudge-0.01/
Perl interface to UVa Online Judge System (Valladolid Programming Competition)
----
macro-0.02
http://search.cpan.org/~gfuji/macro-0.02/
An implementation of macro processor
----
mpp-7
http://search.cpan.org/~pfeiffer/mpp-7/
----
weather-0.11
http://search.cpan.org/~bdfoy/weather-0.11/
fetch weather data
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Mon, 01 Sep 2008 01:45:51 -0700
From: jaycx2.3.calrobert@spamgourmet.com.remove (Robert Maas, http://tinyurl.com/uh3t)
Subject: Re: The Importance of Terminology's Quality
Message-Id: <rem-2008sep01-003@yahoo.com>
> From: r...@rpw3.org (Rob Warnock)
> In the LGP-30, they used hex addresses, sort of[1], but the
> opcodes (all 16 of them) had single-letter mnemonics chosen so that
> the low 4 bits of the character codes *were* the correct nibble for
> the opcode! ;-}
That's a fascinating design constraint! It would be an interesting
puzzle to find the most efficient design whereby:
- The single-character mnemonics are as easy to memorize as possible;
- The instructions produce as efficient code as possible;
- The mnemonics really do accurately express what the instruction does;
- Minimize total number of instructions needed, maybe fewer than 16;
- With the low-order-four-bits rule of course.
- See also the avoid-ambiguous-sound criterion later below.
By the way, do you remember exactly all the 16 opcodes, or have a
Web reference available?
> [Or you could type in the actual hex digits, since the low 4 bits
> of *their* character codes were also their corresponding binary
> nibble values... "but that would have been wrong".]
Moreso because some of the sounds would be ambiguous, which I
recognized when I first started to use the IBM hexadecimal
standard. See below.
> The LGP-30 character code was defined before the industry had
> yet standardized on a common "hex" [sic, "hexadecimal", base 16
> not base 6!!!] character set,
Before IBM had decided to use hexadecimal in their abend coredumps
from their System/360 and by their 800-pound-gorilla status they
got everyone else to use that ABCDEF system.
> they used "0123456789fgjkqw".
That doesn't make sense. The low-order four bits of those letters
aren't consecutive ascending values from 9+1 to 9+6. Did you make a
typo, or did you explain something wrong?
(map 'list #'char-code "0123456789fgjkqw")
=> (48 49 50 51 52 53 54 55 56 57 102 103 106 107 113 119)
(loop for n in * collect (rem n 16))
=> (0 1 2 3 4 5 6 7 8 9 6 7 10 11 1 7)
Now if you used this sequence of letters instead:
(map 'list #'char-code "0123456789jklmno")
=> (48 49 50 51 52 53 54 55 56 57 106 107 108 109 110 111)
(loop for n in * collect (rem n 16))
=> (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15)
Unfortunately o looks like 0, and l looks like 1.
Anyway, what I hated about IBM's hexadecimal notation was:
- A0 would be pronounced "Ay-tee", which sounds too much like "Eighty".
- 1A would be pronounced "Ay-teen", which sounds too much like "Eighteen".
- On the lineprinters where we get our abend listings, the capital
D and digit 0 (which didn't have any diagonal slash) looked almost
identical when the ribbon was going bad, as it always was.
- Likewise B and 8 looked nearly identical.
- Likewise E and F often looked nearly identical of lower part of E
was hitting bad part of ribbon.
Now for single-character mnemonics for four bits of instruction
opcode, to avoid any two characters that look too similar:
0 1 2 3 4 5 6 7 8 9
A B C D E F G H I J K L M N O
P Q R S T U V W X Y Z
We obviously have no choice for KLMNO, so because of look-alike we
can't use 0 or D or Q, so we have to use P instead of 0, so our choices
look like:
1 2 3 4 5 6 7 8 9
A B C E F G H I J K L M N O
P R S T U V W X Y Z
If we have an opcode that sets a register to 1, or clears
register#1, we might use mnemonic "1" for that instruction, but
otherwise we must avoid using digits, use letters only.
1
A B C E F G H I J K L M N O
P R S T U V W X Y Z
We can't use both U and V, and we can't use both E and F, and we
can't use both 1 and I, but we're stuck using both M and N, sigh.
At this point I can't decide which branches of the search to
discard and which to fix, so I'll stop analysing this puzzle.
(With lower-case characters different combinations were mutually
exclusive, such as l and 1, but I was doing upper case here.)
If punctuation is allowed, then + - * / = < > would make dandy
mnemonic opcodes for the obvious instructions.
If characters that look like arrows can be used for push and pop,
then we have V for push and ^ for pop.
If characters that look like arrows can be used for moving
left/right in RAM, or shifting bits in a register, then we have <
for left and > for right.
I wonder if solving this puzzle will yield yet another esoteric
programming language?
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1830
***************************************
