[REBOL] Re: how do I get ampm format for time?
From: bobr:dprc at: 21-Jan-2001 5:22
At 12:40 PM 1/20/01 -0800, Jeff wrote:
> Howdy, Senator Racko:
>
> > #1) I consider that most of you overlooked a biggie.
>
> Likewise:
>
> Some of us (me) had no idea this was intended as a
> Programming Challenge (way too busy to read the whole
> thread), and was only paying attention when they noticed a
> bug in some posted code.
I am grateful for the help.
Yes, I see that early on in the thread the conversion happened to time!
from the unspecified obj/time form. Looks to me like the olde gossip game
(where noise introduced early on gets amplified) happens here too.
> Of course, it's best to always post code that you think is
> well polished...
I see now where my own "polishing" may have broken my example!!
(smile)
> A suggestion: Threads that are Programming Challenges should
> put "[PROGRAMMING CHALLENGE]", or something like that, in
> the subject line so I can avoid accidentally posting in
> those threads. (-:
EEK! if you stop posting then many of us will not really learn from you.
Every thread I post with "How do I" subject is designed to be saved for
training others.
in fact it seems we are on the anniversary of this thread-prefix ...
>I am activating this thread and others like it
>with the same prfix to solve some real problems.
>Likely someone (hint) will capture these for the knowledge base.
>
>What will follow on this thread set are
>pieces of functionality I am taking advantage of
>in some other language or some other real-world app.
>
>I code in lots of things.
>You should expect to see stuff on this thread
>in C, squeak, expect, python plus a few more
>as I am the custodian of at least 2 other rare languages. ...1/18/00
Though I have to filter a lot of email that comes generally to the list, I
keep filters on this prefix wide open and read them all. Sometimes the
responses I get back are not appropriate.
For several I have injected, there hasn't been much discussion
stimulated. For this I blame myself but rather than pester, I have decided
to actively-listen.
I would rather deal with some crankyness or upset than ask questions on a
prefix that
nearly guarantees that the people who can make a difference about it will
ignore it.
They aren't all programming-challenges either since I have plenty of
material to cover
that deals with issues and conventions for which I believe there is not a
pleasant programmable solution. Eye openers for people who design the
language and its environment.
For this ampm example I was able to start with a program that worked (maybe
a bit quirky).
I could tell when writing it that I could do better but I was already
applying the best
series of principles at my disposal. So, with an interest of becoming a
better coder myself,
I introduced it as a "make my code succinct" thread. Meanwhile something
even deeper bothered me -- That there are many ways to incorrectly
construct such a simple function.
I was counting on the fact that in other areas, RT has put in their own
code in subsequent
releases to head off common errors before they bite someone.
In addition I felt I could get the real advocates (those with time) to
think about the deeper problem as a lead-in to an eye opener about
refinements to basic types and how they evolve.
If I start small with a real-world example I get even better attention.
Among the things I was trying to stir up was discussion about how
folks (inside or outside RT) decide what is a (possibly contributed)
mezzanine function, what goes into a datatype-refinement and what gets
left out altogether. That exact decision strategy is one I think
others (outside of RT) would like to know so we can more appropriately
pitch our suggestions.
Of course I could infer one -- and after writing an elaborate paper about
it discover that
the answer is simply: "oh, Carl decides that! :)"
which is only funny up to the point
you start thinking about buying more Carl-insurance.
Jeff, you have demonstrated great flexibility in adapting and understanding the
snips posted which is to your credit. Yours was also the easiest to decouple
into separate refinements.
I am sorry you are so pressed for time to not be able to
go back to the first thread in a series.