Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31203
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: MSP430-Stamp |
| Date | 2014-06-05 15:57 +0200 |
| Organization | 1&1 Internet AG |
| Message-ID | <lmpt18$7k2$1@online.de> (permalink) |
| References | (4 earlier) <7xbnudsz5m.fsf@ruckus.brouhaha.com> <lmdos0$gl9$1@online.de> <7x4n05gtt7.fsf@ruckus.brouhaha.com> <lmfu8n$95f$1@online.de> <7xbnu7ewo7.fsf@ruckus.brouhaha.com> |
Paul Rubin wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>> The amount of bugs in a reviewed and "debugged" code-base is roughly
>>>> the same per kLoC..
>>> What? No I don't believe that--for example TeX has had very few bugs
>>> reported in its entire history, while Linux has had hundreds.
>> TeX is an awfully small program by modern standards. ... Linux has
>> more than 10 million LoCs. You would expect it to have three orders
>> of magnitude more bugs than TeX. And indeed, it does. The big pile
>> of LaTeX extensions have a lot more bugs than TeX, the program.
>
> Hmm, yeah, that's true about TeX being relatively small but I still
> don't believe the bugs per kloc is similar, and your point about LaTeX
> corroborates that (less care was taken with the LaTeX extensions). I'd
> be interested in actual data. Particularly I haven't found the
> Altran/Praxis claims to be terribly implausible despite being a sales
> pitch:
>
> http://www.crosstalkonline.org/storage/issue-archives/2005/200512/200512-Croxford.pdf
> http://www.spectrum.ieee.org/sep05/1454
Yes, I like the six principles they use. The formal notation is only point
1; point 2 is using e.g. formal proofs to validate that the deliverable
meets the spec (you could also use some test driven design, that would cover
point 2 as well). The next points are very obviously what we Forthers do:
6. Do the hard thing first, with building prototypes and throwing things
that don't quite work away and redoing them, 5. design software that is easy
to validate (by factoring into small chunks that can be verified in
isolation), 4. Saying things only once - this is factoring, creating DSLs
that make it easy to formulate the actual problem in a compact, non-
redundant way, 3. Small, incremental development (add a word and run all the
testing stuff).
I'm mostly happy with this paper; I can recommend reading it and using that
approach. What I think can be done better is the specification stuff.
Actually the thinking that you should use a formal method to write down your
spec is *right*. Fundamentally *right*. That's not what I'm going to argue
about. The wrong here is that you have to write the formal spec, which is
actually a programming language of sorts (as it is formal and has a well-
defined semantics), and *then* have to write it again in another programming
language (the implementation language). Don't. Instead try to compile your
formal language; this is quite often possible, way more often than you think
(e.g. Verilog was originally designed as specification language to formally
verify hand-drawn circuits; but it soon was compiled instead). Or better:
Make a formal language that allows you to specify your problem easily, i.e.
a DSL.
The "say things only once" contradicts the formal spec. You should really
say things only once, and thus you must spend the effort (i.e. writing a
DSL) to be able to say things only once. The code you use to solve your
problem must be close to what you expect from a specification language.
The zero-defect example that they list in the end of the article is just
10kLoCs, and it was written quite fast (38LoCs/day is really fast). If you
want to deliver zero-defect products, you absolutely have to be small. And
of course you need a sound development approach that gets you a low
defect/kLoC rate. Because with the usual approach, you get out of the
defect-free zone at 1kLoC. 1kLoC is not enough.
>> People have analyzed security relevant programs in different programming
>> languages, and the number of security problems per amount of code was
>> about
>> equal. Java Programmers make different mistakes.
>
> 1. I don't think you can consider all "security problems" to be
> equivalent. Spilling keys is much worse than almost any protocol error!
Nope. Spilling keys is just as bad as e.g. not detecting a MITM attack.
With spilled keys, you can attack the connection as man in the middle. If
the code contains a bug that prevents detecting the MITM attack without the
attacker needing the key, the effect is the same. This sort of "goto
fail;"-Bug (we have seen them in almost all SSL implementations with the
Frankencert suite) is not crashing the program, it is not exposing any
memory or such.
The assumption that Java helps you to avoid crazy stuff IMHO is completely
unfounded. The actually only crashs in my Gforth Android app that Google
reported to me as ANR were in the few hundred lines of Java code, and they
were null pointer exceptions. I got null pointers I didn't expect I would
(nor does the spec of these callbacks say they could be null pointers, but
they were).
> 2. I think what may really be going on here is a kind of "risk
> thermostat" effect, where bugs decrease to a certain level because that
> level is tolerable to the development and release process, an issue
> orthogonal to the programming language. E.g. a typical internet shop
> will develop and test their code til it seems to work, then (if we're
> lucky) they release it to interested customers for beta test, collect
> further bug reports and fix those, and then when the bug reports slow
> down enough or stop, they release to production. Bugs are considered
> under control if enough less time is spent fixing them than implementing
> new features.
Maybe.
> For a lolcat app, that's not too bad a process. It's like making
> consumer electronics: if a DVD player basically works and doesn't break
> too easily, customers are happy. They don't want to pay 10x as much for
> a player programmed in Ada.
This assumes that the player written in Ada would work much better... an
unfouned assumption.
> And on the internet you can quickly roll
> out updates, which also feeds (crappy or streamlined, you pick the term)
> dev and test processes.
Yes.
> For security code one really needs to seek to affirm the absence of
> bugs, rather than checking for their presence and saying "ok" if none
> are noticed. The code should preferably be treated as a mathematical
> object that one can prove theorems about, rather than an engineering
> artifact whose behavior can only be inferred from observing some tiny
> fragment of the state space.
It's not just the code itself.
>> Yes, it [OpenSSL] still is way too big... I hope they don't stop at
>> throwing out half of the code.
>
> One of the guys hacking code out of OpenSSL at a big web site recently
> told me they really do need a lot of the bloaty-looking code in it, that
> deals with buggy browsers, weird certificates, etc.
They are taking the Postel principle way too far here. A widely used
encryption software can be used to sanitize the Internet from these things:
Fail on the weird certificates, let the buggy browers fail, too. This
causes people to notice the bugs, and fix them.
This is like proof-of-the-concept attacks security experts often are
required to write to kick some asses and make sure people start doing
something. People are lazy. If you work around their bugs, they are happy.
Don't. Make them comply.
In security, the Postel principle is simply wrong. You have to aim at zero
bugs, and therefore, you must have a zero tolerance attitude. This is the
exact opposite of the Postel principle.
>>> In the real world you have to interoperate with the stuff that's out
>>> there.
>> No, the stuff out there doesn't work and needs to be replaced, for god's
>> sake! In the real world, you have people and machines who communicate,
>> and apps who had no compatibility whatsoever with existing protocols like
>> WhatsApp did have 100 million customers after a few years.
>
> That works when all endpoints of the application are controlled by a
> single organization. The issues with SSL are more like those of email
> or IPv4, where many independently controlled entities communicate with
> each other. If you want to design science fiction solutions for future
> generations, that's great as long as you recognize what it is. If you
> want to solve today's problems today, that means dealing with the stuff
> that's out there.
The stuff that's out there is the problem.
>> This assumption that you have to stick with the heapload of shit that's
>> out
>> there has been proven wrong quite often. You have situations where you
>> need interoperability, and you have situations where you don't need that.
>
> In an odd (and bad) way, the desktop computer world is actually
> converging towards everything being controlled by one organization
> (i.e. Google). We don't even see word processors, spreadsheets, or
> email clients on desktops any more. It's all Gmail and Google Docs.
> Nobody is willing to install desktop apps these days.
That's not true. A lot of people do install things like Google Drive and
DropBox, where the brower can't do everything. The reason why people use
Google Docs is that the cloud is so much more comfortable. And that's the
reason why they install DropBox: It makes their different devices
interoperate without problems.
The fact that sendind all your data through Google means sending all your
data through the NSA is something people like to ignore.
> It may be a little different in the mobile space, where people will
> install unlimited spyware from "app stores"--that's how Whatsapp got
> around. Getting to that level of popularity isn't easy though, and even
> 100 million is only a few percent of the internet's users. Browsers
> with SSL reach close to 100%.
I was talking about how long it took to get there. Browsers with SSL took
way longer to reach the 100 million users. SSL is about 20 years old, it is
computer stone age.
>> The world outside I need to bother about is that I must pass through the
>> routers that constitute the current Internet. I use UDP for that.
>
> I'm amused by the terrifying vision of enough applications migrating to
> browsers, simultaneously with net2o succeeding, so we end up with
> in-browser net2o stacks written in Javascript.
Haha.
>> [SSL] is broken in so many ways that we have to replace it. It can't
>> be fixed from within, the spec is already broken beyond repair (things
>> like the CA system),
>
> The CA system is still with us because alternatives haven't fared better
> in implementing SSL's goals. It's not especially a technical weakness
> of SSL. I'd like to know how net2o is going to solve this problem.
> Replace SSL CA's by making people go to key signing parties before they
> can buy shoes online?
No. The PGP signing party model is even older and more broken than the PGP
model. We can do a lot better now. The first thing to realize is that the
far easier SSH model ("remember the first contact") is already far better
than the CA system. It is not perfect, but at least an attacker must be
persistent ("captive environment"), and really intercept every connection.
However, we know that SSL's CA system in a captive environment doesn't work,
either: Some CAs have issued wildcard certificates for exactly those boxes
that do DPI and filter the traffic for captive environments (usually inside
a company or a totalitarian country).
The next problem is that the CA system solves a problem that doesn't need
solving: It is caused by the fact that the way to find the shop is not
related to its key. That's not the case in net2o: To find the shop, and
make contact, you already need to know the key. You might have got that
from a QR coded ad (bad idea: pranksters might have replaced that QR code),
or from a shop search engine and price comparison page on the Internet. So
that one would establish a trust chain, and the good thing is: You can use
several trust chains to increase the strenght. If the shop is found in
serveral price search sites, and its key is identical, your trust level can
be much higher.
>> and the glacial speed it has had in the past to improve known spec
>> bugs (like adaption of TLS 1.2 to over TLS 1.0 and SSL3)
>
> I'll be interested to know how quickly net2o protocol changes are
> deployed, once there are hundreds of implementations, and it's running
> in billions of mobile phones (many of them obsolete and no longer
> receiving updates), home routers, industrial machinery, etc.
The net2o I'll implement will include an update path (and I won't certify
anything without such an update path as "net2o compatible and secure").
It's actually pretty trivial, because it's just sharing stuff - this is a
functionality net2o comes with anyways, and the encryption stuff assures you
that you get the updates from the same party you got the original version.
In any case: If the update path feature is missing, the security is already
compromised. Since net2o will contain a distribution tree for things like
Justin Bieber's tweets, the estimation is that a small patch can spread to
every net2o user on the entire planet in less than a second (i.e. to
billions). This stuff happens by combining all those things that are
necessary anyways.
>>> Don't forgot the requirement that it perform comparably to OpenSSL,
>> It performs far better. I know that performance is important,
>
> OK, I see it uses Donna (ECC implementation) rather than a Forth
> implementation, so fine, other stuff can be handled similarly. Note
> there are faster ECC implementations than Donna now.
Which one? I'm deliberately using Dan Bernstein's Ed25519 curve, because
it's signature algorithm doesn't have the random number design problem of
ECDSA, and the implementation is fast. Dan Bernstein's SUPERCOP code is
slightly faster, but non-portable, as it is written in assembler.
>> I wouldn't even considder something with the performance of OpenSSL to
>> be a contender. The competition is unencrypted communication, which
>> is still used by a lot of people.
>
> That's mostly because of deployment and configuration hassles rather
> than performance.
Maybe; however, a lot of web sites used RC4 only because it was fastest.
Performance does matter. Of course, configuraton hassles are to be avoided
at all costs, too. This thing has to work out of the box.
>>>Python, Lisp, or Erlang>
>> Yes, these programming languages are all interactive. If you cherry-pick
>> languages that have similar features as Forth on a particular topic, you
>> will get similar results.
>
> Well yes, you claimed Forth's interactivity was supposed to prevent
> bugs. I listed other interactive languages to indicate it's still quite
> possible to deploy buggy code despite the availability of interaction.
Non-conclusive logic: Interactive languages makes it more fun to squash out
bugs.
>>> The bugs of course usually manifest as non-catastrophic runtime
>>> exceptions,
>>
>> Why do people always think that a runtime exception is non-catastrophic?
>> The famous Ariane 5 debacle was caused by "non-catastrophic runtime
>> exceptions".
>
> What? No, that one was catastrophic and tools like SPARK put a lot of
> emphasis into proving that code is exception-free, for use in critical
> realtime systems. But we're talking about internet protocols, which are
> not realtime in the same way, and where applications must allow that the
> internet itself is inherently unreliable.
Yes.
> If (say) a Java SSL stack
> throws an exception on someone trying a Heartbleed exploit, the result
> is that client experiencing a dropped connection, which is probably what
> you want anyway (plus you get a traceback in the server log and maybe an
> accompanying pager alert, rather than having the bug go unnoticed for
> years).
Maybe you want the client to renegotiate so that you can inject some MITM
attack which is only possible for renegotiation? We had bugs in SSL where
the exploit was exactly this sort of operation.
>> A runtime exception which stops the usual flow, and which isn't
>> properly handled, can be catastrophic for a secure network protocol.
>> An unexpected runtime exception quite likely won't be properly
>> handled.
>
> If the protocol is any good it has to be able to handle someone
> maliciously intercepting the connection and maybe even inserting their
> own data. If you treat exceptions (normally those will come from the
> i/o system) as similar to someone cutting the wire (i.e. report an
> error and give up), you're most of the way towards a sensible solution.
Ok, two things here: If you receive a packet that doesn't decrypt well, you
have to drop that packet and continue as if there wasn't anything.
Otherwise, you make it dead easy for someone to DoS you. If you receive a
packet that does decrypt (and the checksum is ok), you can assume that it
did originate from your communication partner. If there is something inside
that packet that is fishy, and not according to the protocol, you can indeed
just cut the wire and mark that communcation partner as "fishy".
>>> The Haskell QuickCheck tool (basically an automatic fuzz tester)
>> Fuzz testers have their place, but the usually way to go is that you
>> first
>> have to make your program *work* at all. That phase requires injecting
>> known good data, and observing what happens.
>
> Yes, and you have to test at the edge values, which are not always so
> easy to figure out, especially if you're the code author and if you over
> looked something in coding you're likely to also overlook it in testing.
And then you are also likely not to specify the properties to check that
problematic edge of your code...
> The cool thing about QuickCheck is you write the desired properties as
> the test, and QuickCheck itself generates the values, doing a reasonable
> job at guessing the edge cases itself, using Haskell's fine-grained type
> system to determine the possible good values. It frequently hits stuff
> that manual testing misses.
Sounds good. And it follows the idea that you need to know your object
under test to actually produce the tests. A question would be: Could we
adapt that sort of testing to Forth? Maybe together with an analytical
compiler to produce efficient code? That compiler performs enough analysis
of the code to know the stack effect, so it can compare that to the
documentation (which is a specification). It also could extract values that
cause conditions to go either one or the other way.
Usually, the thing with Forth's one-liners however is that you have complete
oversight.
>> Maybe the boilerplate fillers don't like doing this with interactive
>> testing, i.e. a "test first" strategy, where you write a test which
>> you can't run, because the program under test hasn't been written yet.
>
> I'm not sure what you're getting at here. What happens when you
> refactor the program? Do you have to interactively re-test all the
> words?
No, the point here is that you need your object under test to develop the
tests, see your Haskell thing above. The opposite of "write the tests
first" is not "don't write any regression tests". Of course, when I
refactor some parts of my program, I need to test the refactored definitions
and run the integration tests. Serious refactoring often comes with a
changed API, so the old unit tests don't work anymore, either. The
integration tests still should work.
>> No, the thing you really need first is that you don't end up with a
>> big program.
>
> Nice work if you can get it.
It requires an unforgiving attitude at making things simple.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 21:35 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 19:09 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 19:13 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 23:00 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 20:25 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 20:23 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 22:15 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 15:13 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 13:51 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 21:08 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 12:22 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 21:41 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 13:28 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 17:55 -0400
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 16:29 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 14:18 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 18:07 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 17:24 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 11:10 +0200
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-02 10:57 +0000
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 13:34 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 20:10 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 20:29 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 21:02 -0700
Re: MSP430-Stamp "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-30 04:05 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 15:13 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 19:57 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 23:32 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 21:07 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 02:39 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-07-17 12:40 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-17 16:08 -0400
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-18 00:06 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-07-18 08:22 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-18 23:42 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-18 18:28 -0400
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 01:41 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-18 19:48 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-07-18 16:59 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 14:30 +0200
Re: MSP430-Stamp Gary Bergstrom <forthprgrmr@gmail.com> - 2014-07-19 08:23 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-07-21 10:42 +0200
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 03:03 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 07:47 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-31 11:36 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-31 09:34 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 10:09 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-31 10:52 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 01:28 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 22:41 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 02:00 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 23:07 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 03:13 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 07:15 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 12:33 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 09:45 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 13:10 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 18:38 +0200
Re: MSP430-Stamp babruehl@gmail.com - 2014-06-01 11:40 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 11:13 +0200
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-01 09:50 +0000
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 12:47 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 04:05 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 12:39 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 10:00 -0700
Re: MSP430-Stamp babruehl@gmail.com - 2014-06-01 11:45 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 14:57 -0400
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-01 12:01 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 15:12 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 03:12 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 14:02 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-31 03:33 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 07:19 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-31 12:01 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 09:15 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 13:51 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-31 14:20 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 14:51 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-05-31 16:22 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-01 01:33 +0200
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-05-31 17:31 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 21:48 -0700
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-05-31 19:12 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 22:25 -0700
Re: MSP430-Stamp stephenXXX@mpeforth.com (Stephen Pelc) - 2014-06-01 09:45 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 04:16 -0700
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-01 08:51 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 21:03 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-01 21:17 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-04 22:46 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 13:27 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 08:39 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 16:10 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:10 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 19:52 +0000
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 23:25 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 15:02 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 10:56 +0000
Correct Software and Specifications (was Re: MSP430-Stamp) Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-09 09:59 +0100
Re: MSP430-Stamp mhx@iae.nl - 2014-06-05 14:30 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 10:59 +0000
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 15:57 +0200
Formal specifications etc. (was: MSP430-Stamp) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-05 15:34 +0000
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:48 -0700
Re: Formal specifications etc. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-05 19:46 +0000
Re: Formal specifications etc. (was: MSP430-Stamp) Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 23:02 +0200
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 14:15 -0700
Re: Formal specifications etc. rickman <gnuarm@gmail.com> - 2014-06-05 17:33 -0400
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 15:32 -0700
Re: Formal specifications etc. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-06 04:00 -0500
Re: Formal specifications etc. (was: MSP430-Stamp) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 11:05 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:01 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-06 01:09 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-05 22:01 -0400
Re: MSP430-Stamp stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-31 16:47 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 12:11 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-06 12:54 +0200
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 11:39 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-02 12:15 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-03 10:26 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 12:18 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-02 10:04 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-03 11:51 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 13:33 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-06 13:02 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 17:31 -0400
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-06 16:30 -1000
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 22:52 -0400
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-07 11:58 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-07 11:40 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-07 20:01 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 16:05 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-08 22:28 -0400
Re: MSP430-Stamp Gary Bergstrom <forthprgrmr@gmail.com> - 2014-06-08 20:36 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 21:38 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 14:36 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 02:45 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:18 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 15:57 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 16:20 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 20:42 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 21:05 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-04 10:43 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 21:28 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-03 22:43 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 23:31 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-04 04:13 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 01:41 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 01:51 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-03 16:19 +0100
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 09:14 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 13:19 -0400
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-03 07:43 -1000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 20:56 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-04 10:51 +0000
Re: MSP430-Stamp VisualForth <babruehl@gmail.com> - 2014-06-04 04:06 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 21:26 -0400
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-06 20:40 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-07 03:18 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-07 04:35 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-07 12:01 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:47 -0700
Re: MSP430-Stamp Mikael Nordman <oh2aun@gmail.com> - 2014-06-09 09:28 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:35 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-11 10:43 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 15:52 -0700
Re: MSP430-Stamp Coos Haak <chforth@hccnet.nl> - 2014-06-12 02:06 +0200
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 15:13 -1000
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-12 02:16 -0700
Re: MSP430-Stamp Mikael Nordman <oh2aun@gmail.com> - 2014-06-11 12:56 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 16:46 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:49 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-09 09:47 -0700
Re: MSP430-Stamp Rikard Lang <rikard.lang@gmail.com> - 2014-06-09 23:16 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-10 07:48 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:23 -0700
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-11 18:00 -0500
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 02:14 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-12 02:13 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 13:04 -0400
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-12 18:06 -0500
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 19:29 -0400
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-13 18:48 -0500
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:26 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-11 10:45 -0700
Re: MSP430-Stamp JUERGEN <epldfpga@aol.com> - 2014-06-13 00:03 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-18 11:11 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-18 05:27 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-18 12:29 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-17 16:09 -0400
csiph-web