Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #20606 > unrolled thread

Mecrisp on the TI Stellaris Launchpad

Back to article view | Back to comp.arch.embedded

Contents

  Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-02 21:08 -0400
    Re: Mecrisp on the TI Stellaris Launchpad sbattazzo@gmail.com - 2015-04-13 16:18 -0700
      Re: Mecrisp on the TI Stellaris Launchpad sbattazzo@gmail.com - 2015-04-13 16:25 -0700
        Re: Mecrisp on the TI Stellaris Launchpad sbattazzo@gmail.com - 2015-04-13 16:33 -0700
          Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-13 21:45 -0400
            Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-13 21:47 -0400
              Re: Mecrisp on the TI Stellaris Launchpad sbattazzo@gmail.com - 2015-04-14 07:33 -0700
                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-14 14:38 -0400
      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-16 14:24 -0700
        Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-16 15:11 -0700
          Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-16 23:37 -0400
            Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:59 -0700
              Re: Mecrisp on the TI Stellaris Launchpad Mel Wilson <mwilson@the-wire.com> - 2015-04-17 13:16 +0000
            Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 00:19 -0400
              Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-16 21:56 -0700
                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 14:47 -0400
                  WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-17 15:12 -0400
                    Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-17 20:14 +0000
                      Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-17 16:59 -0400
                    Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking David Brown <david.brown@hesbynett.no> - 2015-04-18 10:00 +0200
                      Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-18 09:32 -0400
                        Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-18 15:15 +0000
                          Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-18 11:31 -0400
                        Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line   Breaking Niklas Holsti <niklas.holsti@tidorum.invalid> - 2015-04-18 19:21 +0300
                          Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line   Breaking rickman <gnuarm@gmail.com> - 2015-04-19 16:39 -0400
                        Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking Alan Adams <alan@adamshome.org.uk> - 2015-04-18 18:52 +0100
                        Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-18 18:55 -0400
                          Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking The Natural Philosopher <tnp@invalid.invalid> - 2015-04-19 09:13 +0100
                          Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-19 13:22 +0300
                            Re: WAS: Mecrisp on the TI Stellaris Launchpad  IS: Thunderbird Line Breaking David Brown <david.brown@hesbynett.no> - 2015-04-19 22:09 +0200
                  Re: Mecrisp on the TI Stellaris Launchpad mm0fmf <none@mailinator.com> - 2015-04-17 21:15 +0100
                    Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 17:02 -0400
                      Re: Mecrisp on the TI Stellaris Launchpad mm0fmf <none@mailinator.com> - 2015-04-18 17:06 +0100
                        Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 16:57 -0400
                          Re: Mecrisp on the TI Stellaris Launchpad Alan Adams <alan@adamshome.org.uk> - 2015-04-20 09:33 +0100
                          Re: Mecrisp on the TI Stellaris Launchpad mm0fmf <none@mailinator.com> - 2015-04-20 18:03 +0100
                            Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-21 01:16 -0400
                  Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:20 -0400
                    Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:24 -0700
                      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:40 -0400
                        Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:57 -0700
                    Re: Mecrisp on the TI Stellaris Launchpad Mel Wilson <mwilson@the-wire.com> - 2015-04-18 02:14 +0000
                      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 02:05 -0400
                        Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 10:16 +0200
                          Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 09:56 -0400
                            Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 17:46 +0200
                      USB serial ports, was: Re: Mecrisp on the TI Stellaris Launchpad Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2015-04-18 18:34 +0000
                    Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 10:04 +0200
                    Re: Mecrisp on the TI Stellaris Launchpad Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-18 09:38 +0100
                      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 11:04 -0400
                        Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 17:54 +0200
                        Re: Mecrisp on the TI Stellaris Launchpad hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) - 2015-04-18 15:36 -0500
                        Re: Mecrisp on the TI Stellaris Launchpad Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-04-23 07:59 +0100
                          Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 14:35 -0400
                            Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 15:44 -0400
                              Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-08 12:00 -0400
                                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 03:36 -0400
                                  Re: Mecrisp on the TI Stellaris Launchpad Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-05-10 10:32 +0100
                                    Re: Mecrisp on the TI Stellaris Launchpad Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-05-10 12:56 +0300
                                    Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 10:48 -0400
                                      Re: Mecrisp on the TI Stellaris Launchpad The Natural Philosopher <tnp@invalid.invalid> - 2015-05-10 16:05 +0100
                                      Re: Mecrisp on the TI Stellaris Launchpad Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2015-05-10 23:26 +0000
                                  Re: Mecrisp on the TI Stellaris Launchpad Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2015-05-10 09:37 +0000
                                    Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 11:16 -0400
                                      Re: Mecrisp on the TI Stellaris Launchpad Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2015-05-10 23:42 +0000
                                        Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-11 02:17 -0400
                                  Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-10 11:41 +0000
                                    Re: Mecrisp on the TI Stellaris Launchpad Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-05-10 16:56 +0100
                                      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 13:01 -0400
                  Re: Mecrisp on the TI Stellaris Launchpad lasselangwadtchristensen@gmail.com - 2015-04-18 12:13 -0700
              Re: Mecrisp on the TI Stellaris Launchpad stephen@mpeforth.com (Stephen Pelc) - 2015-04-18 19:22 +0000
                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 17:04 -0400
                  Re: Mecrisp on the TI Stellaris Launchpad Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-04-20 13:24 +0300
                    Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 13:23 -0400
                      Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-22 20:44 +0300
                        Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 13:51 -0400
                      Re: Mecrisp on the TI Stellaris Launchpad Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-04-22 19:10 +0000
                        Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 15:31 -0400
                          Re: Mecrisp on the TI Stellaris Launchpad Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-04-23 02:08 +0000
                            Re: Mecrisp on the TI Stellaris Launchpad Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-04-24 02:52 +0000
                              Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 14:40 -0400
                                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 15:42 -0400
                  Re: Mecrisp on the TI Stellaris Launchpad sbattazzo@gmail.com - 2015-04-21 09:34 -0700
                    Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 14:57 -0400
                    Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 15:35 -0400
            Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:52 +0000
              Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-17 14:05 +0300
              Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:56 -0700
                Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-17 17:26 +0200
                Re: Mecrisp on the TI Stellaris Launchpad glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-17 17:01 +0000
            Re: Mecrisp on the TI Stellaris Launchpad Blajrs Jrolrsen <boegre@no.com> - 2015-04-17 13:36 +0000
              Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 14:42 +0000
                Re: Mecrisp on the TI Stellaris Launchpad Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-04-18 00:25 +0200
                  Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:03 -0400
                    Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:14 -0700
                      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:26 -0400
                        Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:32 -0700
                          Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:47 -0400
                          Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-18 08:47 +0000
                            Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 11:19 -0400
                              Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-18 15:52 +0000
                                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 17:07 -0400
                                Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-06-09 03:04 -0400
                    Re: Mecrisp on the TI Stellaris Launchpad Robert Wessel <robertwessel2@yahoo.com> - 2015-04-18 00:11 -0500
                    Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 10:32 +0200
                      Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 11:26 -0400
                        Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 17:57 +0200
                          Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-18 09:42 -0700
                            Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 17:11 -0400
                    Re: Mecrisp on the TI Stellaris Launchpad Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-04-18 12:19 +0200
                      Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-18 15:16 +0300
                        Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 19:57 +0200
                          Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-18 23:11 +0300
                            Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-19 21:32 +0200
                              Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-19 23:04 +0300
                  Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 09:15 +0000
                    Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 12:17 +0200
                      Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 13:08 +0000
                        Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 20:17 +0200
                          Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 15:33 +0000
              Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 14:52 -0400
              Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:06 +0000
        Re: Mecrisp on the TI Stellaris Launchpad lasselangwadtchristensen@gmail.com - 2015-04-16 16:18 -0700

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#20717

In article <mgtsk2$v6j$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 4/18/2015 4:47 AM, Albert van der Horst wrote:
<SNIP>
>
>So is noforth documented much?  That is one problem I'm having with
>Mecrisp.  It doesn't have a lot of documentation, which is something I
>would like to work on.  Matthias has ported it to several MSP430s and
>then discovered the ARM CM line.  I think there are some dozen ARM
>targets ready to fire up on eval boards.  He really liked the STM line I
>think.  I have an old Motorolla board that should be worth firing up and
>I think the processor has a version ready for it.  Cool.
>
>But if noforth would get me to my goal more quickly on this task, I
>would like to consider it.  But it looks like it is only for the MSP430
>and not the ARM board I currently have.

I think the documentation of noforth is quite formidable. Not only the
examples, the system itself and the way to make turnkey systems, but also
the metacompiler, which is somewhat rarer.
We (Dutch Forth chapter) are in the process of helping the authors
to make the system somewhat easier to find, (probably BitBucket)
and the authors have GPL-ed it, such that the copyright status is clear.

It is mature, as the example I gave was three year ago, and quite some
improvements have been made, in particular the number of boards that
are supported. But sorry, it is MPS430 only.

>--
>
>Rick

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#20748

On 4/18/2015 11:52 AM, Albert van der Horst wrote:
> In article <mgtsk2$v6j$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/18/2015 4:47 AM, Albert van der Horst wrote:
> <SNIP>
>>
>> So is noforth documented much?  That is one problem I'm having with
>> Mecrisp.  It doesn't have a lot of documentation, which is something I
>> would like to work on.  Matthias has ported it to several MSP430s and
>> then discovered the ARM CM line.  I think there are some dozen ARM
>> targets ready to fire up on eval boards.  He really liked the STM line I
>> think.  I have an old Motorolla board that should be worth firing up and
>> I think the processor has a version ready for it.  Cool.
>>
>> But if noforth would get me to my goal more quickly on this task, I
>> would like to consider it.  But it looks like it is only for the MSP430
>> and not the ARM board I currently have.
>
> I think the documentation of noforth is quite formidable. Not only the
> examples, the system itself and the way to make turnkey systems, but also
> the metacompiler, which is somewhat rarer.
> We (Dutch Forth chapter) are in the process of helping the authors
> to make the system somewhat easier to find, (probably BitBucket)
> and the authors have GPL-ed it, such that the copyright status is clear.
>
> It is mature, as the example I gave was three year ago, and quite some
> improvements have been made, in particular the number of boards that
> are supported. But sorry, it is MPS430 only.

That's one of the things I like about Mecrisp, it is on two families, 
MSP430 and ARM CMx and lots of boards supported.  I'll keep note of 
noforth.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#21175

On 4/18/2015 11:52 AM, Albert van der Horst wrote:
> In article <mgtsk2$v6j$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/18/2015 4:47 AM, Albert van der Horst wrote:
> <SNIP>
>>
>> So is noforth documented much?  That is one problem I'm having with
>> Mecrisp.  It doesn't have a lot of documentation, which is something I
>> would like to work on.  Matthias has ported it to several MSP430s and
>> then discovered the ARM CM line.  I think there are some dozen ARM
>> targets ready to fire up on eval boards.  He really liked the STM line I
>> think.  I have an old Motorolla board that should be worth firing up and
>> I think the processor has a version ready for it.  Cool.
>>
>> But if noforth would get me to my goal more quickly on this task, I
>> would like to consider it.  But it looks like it is only for the MSP430
>> and not the ARM board I currently have.
>
> I think the documentation of noforth is quite formidable. Not only the
> examples, the system itself and the way to make turnkey systems, but also
> the metacompiler, which is somewhat rarer.
> We (Dutch Forth chapter) are in the process of helping the authors
> to make the system somewhat easier to find, (probably BitBucket)
> and the authors have GPL-ed it, such that the copyright status is clear.
>
> It is mature, as the example I gave was three year ago, and quite some
> improvements have been made, in particular the number of boards that
> are supported. But sorry, it is MPS430 only.

It sure seems like the EU is a lot more active in embedded Forth than 
here in the US.  There are three embedded forths that I am aware of. 
4E4th, noforth and mecrisp.  All three are from the area around Germany 
(as far as I can tell).  I have been working with Mecrisp and am at 
quite a disadvantage not knowing the language of the comments.  :(

Still, it's nice to have these tools to work with and be able to run on 
embedded hardware.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#20695

On Fri, 17 Apr 2015 20:03:41 -0400, rickman <gnuarm@gmail.com> wrote:

>On 4/17/2015 6:25 PM, Hans-Bernhard Bröker wrote:
>> Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>>> Blajrs Jrolrsen <boegre@no.com> writes:
>>>> On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
>>>>> Yes, I figured that out.  It seems the current working directory is not
>>>>> considered under Linux for finding executables... really!?
>>
>> Yes, really.
>>
>>> I think it has something to do with more usage of Unix/Linux by
>>> non-programmers (to such an extent that they don't even write their
>>> own shell scripts).
>>
>> I don't think that argument works.
>>
>> There have been platforms where a very large fraction of users never
>> wrote a program of their own.  The biggest of those has to be Microsoft
>> Windows, closely followed by MacOS.
>>
>> But Unix never was anywhere near the top of that category.  I'm not
>> aware of any system that encouraged users to write their own programs
>> more strongly than Unix did: the whole "toolkit" paradigm almost forced
>> _users_ to become programmers, at least at the shell script level.  And
>> how many other systems did come with a bona-fide HLL compiler right
>> there in the box?
>>
>>> In the old times, we had "." first in the PATH.  If I am working on a
>>> new version of Gforth, and am in the build directory of Gforth, then
>>> saying "gforth" gives me the development version, not the installed
>>> version.
>>
>> And that was baskk-ackward.  If only because it's a whole lot easier to
>> and type the "./" prefix for the exceptional case of wanting something
>> else than the normal instance of a command, than it would be to figure
>> out where the "official" one might be, and type the full path to there
>> every time you want to be sure you get that.
>>
>> The distinction between "gforth" and "./gforth" is way easier to handle
>> than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth"
>> and "gforth".
>>
>>> That disadvantage was worked around by removing the "." from the front
>>> and putting it on the back of the PATH.
>>
>> That workaround would be half-assed at best, because it relies on the
>> obviously flawed assumption that user will never mis-type commands.  But
>> because they do, it's relatively easy for an attacker to pre-load their
>> traps with lots of mis-typed versions of, 'ls', 'cd', etc.
>>
>> One other rather important aspect is that the way Unix does it actually
>> leaves you a _choice_ how you want this handled: _you_ define your $PATH
>> setting, so you can put '.' in there exactly where you want or need it,
>> or not at all. On Microsoft platforms, you have no control over it: the
>> system forces an implied '.' to the front of your PATH, whether you want
>> it or not.
>
>I don't wish to insult anyone.  But I will say that I have tried to 
>learn linux several times and found poor support from the linux 
>community.  Mostly I think there is an attitude that "we" (the linux 
>community) got it *right*, when there are many, many more PC users, even 
>professional programmers, than there are working under Linux.
>
>Ok, everyone is entitled to their opinion.  But the problem arises when 
>it is not understood that this is an opinion, not a universal truth. 
>There are good and bad things about both linux and windows.  I would 
>like to learn about linux now, so I won't ask "why" anymore.  I'll just 
>accept the things that are goofy about it just as I have done with 
>windows for many years.


OTOH, even MS has decided that the Unix behavior is the correct one,
and PowerShell, largely the replacement for the old command prompt,
does *not* search the current directory for executables first.

[toc] | [prev] | [next] | [standalone]

#20700

On 18/04/15 02:03, rickman wrote:

> I don't wish to insult anyone.  But I will say that I have tried to
> learn linux several times and found poor support from the linux
> community.  Mostly I think there is an attitude that "we" (the linux
> community) got it *right*, when there are many, many more PC users, even
> professional programmers, than there are working under Linux.
>
> Ok, everyone is entitled to their opinion.  But the problem arises when
> it is not understood that this is an opinion, not a universal truth.
> There are good and bad things about both linux and windows.  I would
> like to learn about linux now, so I won't ask "why" anymore.  I'll just
> accept the things that are goofy about it just as I have done with
> windows for many years.
>

How people answer questions is going to vary a great deal, no matter 
what the subject and what the group - don't tar all "linux communities" 
as being bad support.  But if you /do/ feel you are getting bad support 
somewhere, ignore them or find another forum - don't stop asking 
questions, and never stop asking "why?".  It's crucial to learning.

I fully agree that there are good and bad things about Linux and 
Windows.  I couldn't do my work with only one of them.

It is the "power users" from Windows that find Linux hardest, precisely 
because there are many small differences that lie under the surface, 
unseen by users who are satisfied by email, browser, media player and a 
few games.

But there are many things about the Unix design that have turned out to 
be very good decisions.  When you look at the differences between Linux 
and Windows, many aspects trace their roots back to the beginnings of 
the systems - for Linux, this was Unix of the 70's, and for Windows it 
was MSDOS.  And then consider where Unix came from - it came from 
serious computing professionals, big companies, big universities, big 
multi-user computers.  It has always been serious stuff, made by serious 
people.  MSDOS, on the other hand, was a con-job pulled off by a couple 
of guys (admittedly quite good programmers), hacked together for a 
marketing exercise that was never meant to be used for real work.

Some Linux users therefore feel completely justified in being arrogant 
about the superiority of the Linux "guts" compared to that of Windows. 
But if it bugs you (and it certainly can be annoying), just ignore it 
and move along.

[toc] | [prev] | [next] | [standalone]

#20714

On 4/18/2015 4:32 AM, David Brown wrote:
> On 18/04/15 02:03, rickman wrote:
>
>> I don't wish to insult anyone.  But I will say that I have tried to
>> learn linux several times and found poor support from the linux
>> community.  Mostly I think there is an attitude that "we" (the linux
>> community) got it *right*, when there are many, many more PC users, even
>> professional programmers, than there are working under Linux.
>>
>> Ok, everyone is entitled to their opinion.  But the problem arises when
>> it is not understood that this is an opinion, not a universal truth.
>> There are good and bad things about both linux and windows.  I would
>> like to learn about linux now, so I won't ask "why" anymore.  I'll just
>> accept the things that are goofy about it just as I have done with
>> windows for many years.
>>
>
> How people answer questions is going to vary a great deal, no matter
> what the subject and what the group - don't tar all "linux communities"
> as being bad support.  But if you /do/ feel you are getting bad support
> somewhere, ignore them or find another forum - don't stop asking
> questions, and never stop asking "why?".  It's crucial to learning.

Thank you for the support.  I *did* let it stop me from learning Linux 
on several occasions.  But now that I have a project for the rPi, I have 
more incentive to dig in.  I'm spending a lot of time with this now.


> I fully agree that there are good and bad things about Linux and
> Windows.  I couldn't do my work with only one of them.
>
> It is the "power users" from Windows that find Linux hardest, precisely
> because there are many small differences that lie under the surface,
> unseen by users who are satisfied by email, browser, media player and a
> few games.
>
> But there are many things about the Unix design that have turned out to
> be very good decisions.  When you look at the differences between Linux
> and Windows, many aspects trace their roots back to the beginnings of
> the systems - for Linux, this was Unix of the 70's, and for Windows it
> was MSDOS.

Lol, I was actually using Unix in the 70's, the era of command line 
processing.  I learned cat I recall... but not much more.  I think I 
used it some more in the 90's, but didn't find that experience rewarding 
at all.  For some reason the delete and backspace keys were reversed on 
our workstations and I was told I could define it any way I wished... 
lol.   Not much good if you don't know how to redefine it.


> And then consider where Unix came from - it came from
> serious computing professionals, big companies, big universities, big
> multi-user computers.  It has always been serious stuff, made by serious
> people.  MSDOS, on the other hand, was a con-job pulled off by a couple
> of guys (admittedly quite good programmers), hacked together for a
> marketing exercise that was never meant to be used for real work.
>
> Some Linux users therefore feel completely justified in being arrogant
> about the superiority of the Linux "guts" compared to that of Windows.
> But if it bugs you (and it certainly can be annoying), just ignore it
> and move along.

I don't care about origins or intent.  I just want to get some work done 
with the minimum of hassle.  I'm still amazed at how slow computers have 
gotten as the CPUs have gotten faster.  The rPi is no exception.  It is 
many times faster and has much more memory than the machine I first got 
on the Internet with.  But I guess browsers and HTML have changed to 
demand more.  That's the main reason why I want to use Forth.  It is 
very light weight and puts little strain on the system hosting it. 
Heck, Mecrisp runs entirely on the target!

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#20719

On 18/04/15 17:26, rickman wrote:

>
> I don't care about origins or intent.  I just want to get some work done
> with the minimum of hassle.  I'm still amazed at how slow computers have
> gotten as the CPUs have gotten faster.  The rPi is no exception.  It is
> many times faster and has much more memory than the machine I first got
> on the Internet with.  But I guess browsers and HTML have changed to
> demand more.  That's the main reason why I want to use Forth.  It is
> very light weight and puts little strain on the system hosting it. Heck,
> Mecrisp runs entirely on the target!
>

"Software gets slower faster than hardware gets faster."

(I can't remember whose "law" that is.)

[toc] | [prev] | [next] | [standalone]

#20722

David Brown <david.brown@hesbynett.no> writes:
>> I'm still amazed at how slow computers have gotten as the CPUs have
>> gotten faster.  The rPi is no exception.  It is many times faster and
>> has much more memory than the machine I first got on the Internet
>> with.  But I guess browsers and HTML have changed to demand more.

Certainly today's web pages have ridiculous amounts of javascript on
them.  Rick could try a simpler browser like dillo (dillo.org), that has
no JS and is very fast, but there's lots of sites that won't work.

>> That's the main reason why I want to use Forth.  It is very light
>> weight and puts little strain on the system hosting it.

Python is nowhere near as light as Forth but it works pretty well on the
Pi, from what I hear.  I used it on a much less powerful board than the
Pi and it was great.

> "Software gets slower faster than hardware gets faster."
> (I can't remember whose "law" that is.)

I thought this was interesting: 

http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

it points out that people have always dealt with unacceptably slow
computations by limiting what they compute.  "Example: In your favorite
sword-fighting video game, are light reflections affected realistically
by sword vibration?"

There's more abstraction and interpretation burning cpu cycles in
today's software, but the software is also doing more for people than it
used to.

[toc] | [prev] | [next] | [standalone]

#20749

On 4/18/2015 12:42 PM, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>> I'm still amazed at how slow computers have gotten as the CPUs have
>>> gotten faster.  The rPi is no exception.  It is many times faster and
>>> has much more memory than the machine I first got on the Internet
>>> with.  But I guess browsers and HTML have changed to demand more.
>
> Certainly today's web pages have ridiculous amounts of javascript on
> them.  Rick could try a simpler browser like dillo (dillo.org), that has
> no JS and is very fast, but there's lots of sites that won't work.
>
>>> That's the main reason why I want to use Forth.  It is very light
>>> weight and puts little strain on the system hosting it.
>
> Python is nowhere near as light as Forth but it works pretty well on the
> Pi, from what I hear.  I used it on a much less powerful board than the
> Pi and it was great.

The rPi is not my target processor, a TI Stellaris Launchpad is.  I want 
to use the rPi as my development system.


>> "Software gets slower faster than hardware gets faster."
>> (I can't remember whose "law" that is.)
>
> I thought this was interesting:
>
> http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf
>
> it points out that people have always dealt with unacceptably slow
> computations by limiting what they compute.  "Example: In your favorite
> sword-fighting video game, are light reflections affected realistically
> by sword vibration?"
>
> There's more abstraction and interpretation burning cpu cycles in
> today's software, but the software is also doing more for people than it
> used to.

Is it really?  I mean, is it doing more *useful* stuff?  I think most 
web sites are loaded with glitz and crap and for the semiconductor 
makers the sites are just noise.  For example TI used to have an 
excellent site, clearly organized with a lot of input from the 
engineering staff or customers.  Now it is full of glitz and advertising 
so that it is hard to find what you want in a way that makes it all easy 
and clear.  The result is pages that run slowly and are hard to even 
scroll.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#20706

Am 18.04.2015 um 02:03 schrieb rickman:

> I don't wish to insult anyone.  But I will say that I have tried to
> learn linux several times and found poor support from the linux
> community.  Mostly I think there is an attitude that "we" (the linux
> community) got it *right*,

In all fairness, from this end your attitude, particularly that 
"really!?", did come across pretty much the same, just applied the 
opposite way.  This attitude thing does cut both ways.

 > when there are many, many more PC users, even
 > professional programmers, than there are working under Linux.

That's the "trillions of flies eat shit, so that must be a good thing!" 
fallacy.  Democracy just doesn't work to decide about technical merit.

[toc] | [prev] | [next] | [standalone]

#20707

On 18.4.2015 г. 13:19, Hans-Bernhard Bröker wrote:
> Am 18.04.2015 um 02:03 schrieb rickman:
> ....
>  > when there are many, many more PC users, even
>  > professional programmers, than there are working under Linux.
>
> That's the "trillions of flies eat shit, so that must be a good thing!"
> fallacy.  Democracy just doesn't work to decide about technical merit.
>

Certainly true, however its implication "this is what flies do, so
I shall not do it" is also a widespread fallacy (e.g. means you will
not consider flying as an option).
  Then the fallacy you point to is what most if not all of the
pro linux/gnu arguments are based on.

Your argument (from a previous post) about the user being left to
decide whether to have his current directory as one of his exec
paths is quite correct.

BTW, does anyone know how much unix is there within Android?
Its event timings and latencies are *so* pathetic I could not
imagine the entire linux thing would have survived that long if it were
that bad. Good thing tablet devices have become cheap enough to
not regret much if you smash one against the wall.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20724

On 18/04/15 14:16, Dimiter_Popoff wrote:
> On 18.4.2015 г. 13:19, Hans-Bernhard Bröker wrote:
>> Am 18.04.2015 um 02:03 schrieb rickman:
>> ....
>>  > when there are many, many more PC users, even
>>  > professional programmers, than there are working under Linux.
>>
>> That's the "trillions of flies eat shit, so that must be a good thing!"
>> fallacy.  Democracy just doesn't work to decide about technical merit.
>>
>
> Certainly true, however its implication "this is what flies do, so
> I shall not do it" is also a widespread fallacy (e.g. means you will
> not consider flying as an option).
>   Then the fallacy you point to is what most if not all of the
> pro linux/gnu arguments are based on.

That is - at best - an extraordinary exaggeration.  The number of people 
who choose Linux /because/ they don't want to do the same as most people 
(use Windows) is tiny.

There is the argument that one of the many reasons why Linux is (in 
general) more secure than Windows is that there are fewer users of 
Linux, but even that is a minor issue.

>
> Your argument (from a previous post) about the user being left to
> decide whether to have his current directory as one of his exec
> paths is quite correct.
>
> BTW, does anyone know how much unix is there within Android?

The kernel and base system are all Linux.  The gui and many higher-level 
features are Android specific.

> Its event timings and latencies are *so* pathetic I could not
> imagine the entire linux thing would have survived that long if it were
> that bad. Good thing tablet devices have become cheap enough to
> not regret much if you smash one against the wall.
>

It's the gui and user interface that causes this, and that is 
Android-specific.  Much of it is written in Java, and runs on a JVM.

[toc] | [prev] | [next] | [standalone]

#20730

On 18.4.2015 г. 20:57, David Brown wrote:
> On 18/04/15 14:16, Dimiter_Popoff wrote:
>> On 18.4.2015 г. 13:19, Hans-Bernhard Bröker wrote:
>>> Am 18.04.2015 um 02:03 schrieb rickman:
>>> ....
>>>  > when there are many, many more PC users, even
>>>  > professional programmers, than there are working under Linux.
>>>
>>> That's the "trillions of flies eat shit, so that must be a good thing!"
>>> fallacy.  Democracy just doesn't work to decide about technical merit.
>>>
>>
>> Certainly true, however its implication "this is what flies do, so
>> I shall not do it" is also a widespread fallacy (e.g. means you will
>> not consider flying as an option).
>>   Then the fallacy you point to is what most if not all of the
>> pro linux/gnu arguments are based on.
>
> That is - at best - an extraordinary exaggeration.  The number of people
> who choose Linux /because/ they don't want to do the same as most people
> (use Windows) is tiny.
>
> There is the argument that one of the many reasons why Linux is (in
> general) more secure than Windows is that there are fewer users of
> Linux, but even that is a minor issue.

I was being general, I did not mean people chose linux just in order
to be different. I said only "doing something because other people
do it is no better than not doing it for this reason", no unix
etc. implied - though I can see how in this context it may have
come across this way (which was neither intended nor meant).

>>
>> Your argument (from a previous post) about the user being left to
>> decide whether to have his current directory as one of his exec
>> paths is quite correct.
>>
>> BTW, does anyone know how much unix is there within Android?
>
> The kernel and base system are all Linux.  The gui and many higher-level
> features are Android specific.
>
>> Its event timings and latencies are *so* pathetic I could not
>> imagine the entire linux thing would have survived that long if it were
>> that bad. Good thing tablet devices have become cheap enough to
>> not regret much if you smash one against the wall.
>>
>
> It's the gui and user interface that causes this, and that is
> Android-specific.  Much of it is written in Java, and runs on a JVM.
>

This must be it, the sync issues I see are mainly between user
clicks (taps)and what is tapped on - at times many seconds apart,
you tap and tap on a link and after half a minute may be the browser
hears your tapping and takes you to some other link you did not even
suspect was there let alone tap on it. What a mess, if I try to sell
something 1/10th that messy I'll never get away with it.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20740

On 18/04/15 22:11, Dimiter_Popoff wrote:
>
> This must be it, the sync issues I see are mainly between user
> clicks (taps)and what is tapped on - at times many seconds apart,
> you tap and tap on a link and after half a minute may be the browser
> hears your tapping and takes you to some other link you did not even
> suspect was there let alone tap on it. What a mess, if I try to sell
> something 1/10th that messy I'll never get away with it.
>

I think this is entirely up to the app.  Input events get put in a 
queue, normally handled by the main thread (as is common on most gui 
systems AFAIK).  If the app keeps the main thread too busy to see the 
events for a while, you get delays.

[toc] | [prev] | [next] | [standalone]

#20742

On 19.4.2015 г. 22:32, David Brown wrote:
> On 18/04/15 22:11, Dimiter_Popoff wrote:
>>
>> This must be it, the sync issues I see are mainly between user
>> clicks (taps)and what is tapped on - at times many seconds apart,
>> you tap and tap on a link and after half a minute may be the browser
>> hears your tapping and takes you to some other link you did not even
>> suspect was there let alone tap on it. What a mess, if I try to sell
>> something 1/10th that messy I'll never get away with it.
>>
>
> I think this is entirely up to the app.  Input events get put in a
> queue, normally handled by the main thread (as is common on most gui
> systems AFAIK).  If the app keeps the main thread too busy to see the
> events for a while, you get delays.
>

It may be down to some app but it applies to all apps (i.e. there is
no scenario where if one browser window gets stuck you can switch
and talk to some other task, everything stays stuck for a very long
time). Then if an app is allowed to block the system task doing user
I/O this is a very poorly organized system (which it is, it becomes
obvious immediately when one touches it - but it is good to have it
in ones pocket nonetheless, better than nothing anyway).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#20704

=?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBroeker@t-online.de> writes:
>Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>> I think it has something to do with more usage of Unix/Linux by
>> non-programmers (to such an extent that they don't even write their
>> own shell scripts).
>
>I don't think that argument works.
>
>There have been platforms where a very large fraction of users never 
>wrote a program of their own.  The biggest of those has to be Microsoft 
>Windows, closely followed by MacOS.
>
>But Unix never was anywhere near the top of that category.  I'm not 
>aware of any system that encouraged users to write their own programs 
>more strongly than Unix did: the whole "toolkit" paradigm almost forced 
>_users_ to become programmers, at least at the shell script level.  And 
>how many other systems did come with a bona-fide HLL compiler right 
>there in the box?

Pretty much any home computer from the 1970s and 1980s included BASIC.
Yes, an interpreter, but that does not stop anyone from programming.

Anyway, Unix may have the highest proportion of programmers, but it
seems that non-programmers are the primary target of the Linux
distributions these days.  E.g., neither emacs nor vi nor Eclipse is
installed in Debian by default.  Or look at what programming languages
are installed by default.  Only those necessary for running the
scripts, no others.

Actually (and getting back on-topic a little bit) the Raspberry Pi was
created exactly to get away from the current non-programming culture
and get more people to program, like home computers did in the 1980s.

>> In the old times, we had "." first in the PATH.  If I am working on a
>> new version of Gforth, and am in the build directory of Gforth, then
>> saying "gforth" gives me the development version, not the installed
>> version.
>
>And that was baskk-ackward.  If only because it's a whole lot easier to
>and type the "./" prefix for the exceptional case of wanting something
>else than the normal instance of a command, than it would be to figure
>out where the "official" one might be, and type the full path to there 
>every time you want to be sure you get that.
>
>The distinction between "gforth" and "./gforth" is way easier to handle 
>than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" 
>and "gforth".

Not in my experience: If I am in a gforth build directory, I pretty
much always want to call ./gforth rather than /usr/bin/gforth when I
type gforth.  If I want to call /usr/bin/gforth, I either do it from a
different directory, or I say, e.g., gforth-0.7.0.

As for /opt, I don't know where that nonsense comes from, but it
certainly does not come from the original Unix.  Proper programs are
installed in one of the directories that users have in the PATH by
default (such as /usr/bin or /usr/local/bin) rather than somewhere in
/opt (which indicates that the programmer is too lazy to make a
working "make install").

>On Microsoft platforms, you have no control over it: the 
>system forces an implied '.' to the front of your PATH, whether you want 
>it or not.

On Windows and MacOS, the usual way to call a program is to click on
an icon, and AFAIK that works with absolute file names, no PATH
incolved.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#20705

On 18/04/15 11:15, Anton Ertl wrote:
> =?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBroeker@t-online.de> writes:
>> Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>>> I think it has something to do with more usage of Unix/Linux by
>>> non-programmers (to such an extent that they don't even write their
>>> own shell scripts).
>>
>> I don't think that argument works.
>>
>> There have been platforms where a very large fraction of users never
>> wrote a program of their own.  The biggest of those has to be Microsoft
>> Windows, closely followed by MacOS.
>>
>> But Unix never was anywhere near the top of that category.  I'm not
>> aware of any system that encouraged users to write their own programs
>> more strongly than Unix did: the whole "toolkit" paradigm almost forced
>> _users_ to become programmers, at least at the shell script level.  And
>> how many other systems did come with a bona-fide HLL compiler right
>> there in the box?
>
> Pretty much any home computer from the 1970s and 1980s included BASIC.
> Yes, an interpreter, but that does not stop anyone from programming.
>
> Anyway, Unix may have the highest proportion of programmers, but it
> seems that non-programmers are the primary target of the Linux
> distributions these days.  E.g., neither emacs nor vi nor Eclipse is
> installed in Debian by default.  Or look at what programming languages
> are installed by default.  Only those necessary for running the
> scripts, no others.

Most distros install a subset of commonly used tools, and then make it 
easy for others to be installed.  There are vast numbers of tools, 
editors, languages, libraries, etc., commonly used by programmers - it 
would be ridiculous to install 2GB+ of popular programming tools when 
even most full-time programmers won't need them.  (i.e., /you/ might 
want emacs - but someone else will want eclipse, or vim, or jedit, or 
netbeans, or QT tools, etc.).

>
> Actually (and getting back on-topic a little bit) the Raspberry Pi was
> created exactly to get away from the current non-programming culture
> and get more people to program, like home computers did in the 1980s.
>
>>> In the old times, we had "." first in the PATH.  If I am working on a
>>> new version of Gforth, and am in the build directory of Gforth, then
>>> saying "gforth" gives me the development version, not the installed
>>> version.
>>
>> And that was baskk-ackward.  If only because it's a whole lot easier to
>> and type the "./" prefix for the exceptional case of wanting something
>> else than the normal instance of a command, than it would be to figure
>> out where the "official" one might be, and type the full path to there
>> every time you want to be sure you get that.
>>
>> The distinction between "gforth" and "./gforth" is way easier to handle
>> than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth"
>> and "gforth".
>
> Not in my experience: If I am in a gforth build directory, I pretty
> much always want to call ./gforth rather than /usr/bin/gforth when I
> type gforth.  If I want to call /usr/bin/gforth, I either do it from a
> different directory, or I say, e.g., gforth-0.7.0.
>
> As for /opt, I don't know where that nonsense comes from, but it
> certainly does not come from the original Unix.  Proper programs are
> installed in one of the directories that users have in the PATH by
> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
> /opt (which indicates that the programmer is too lazy to make a
> working "make install").

You appear to be supremely confident that your own personal usage of 
Linux, and your own (somewhat lacking and biased) view of OS history, is 
/the/ truth and /the/ right way to do things.  Linux, and Unix in 
general, is all about flexibility and the freedom to use the tools you 
want in the way you want.

So choose the PATH settings that work for /you/, and choose the file 
system organisation that works for /you/.  But don't try and tell 
everyone else that they are lazy or otherwise "wrong" for using a 
different organisation.

>
>> On Microsoft platforms, you have no control over it: the
>> system forces an implied '.' to the front of your PATH, whether you want
>> it or not.
>
> On Windows and MacOS, the usual way to call a program is to click on
> an icon, and AFAIK that works with absolute file names, no PATH
> incolved.
>

That's correct.  But DLL libraries and other files may need to be in the 
PATH (or a library path variable).

[toc] | [prev] | [next] | [standalone]

#20708

David Brown <david.brown@hesbynett.no> writes:
>On 18/04/15 11:15, Anton Ertl wrote:
>> Anyway, Unix may have the highest proportion of programmers, but it
>> seems that non-programmers are the primary target of the Linux
>> distributions these days.  E.g., neither emacs nor vi nor Eclipse is
>> installed in Debian by default.  Or look at what programming languages
>> are installed by default.  Only those necessary for running the
>> scripts, no others.
>
>Most distros install a subset of commonly used tools, and then make it 
>easy for others to be installed.  There are vast numbers of tools, 
>editors, languages, libraries, etc., commonly used by programmers - it 
>would be ridiculous to install 2GB+ of popular programming tools when 
>even most full-time programmers won't need them.  (i.e., /you/ might 
>want emacs - but someone else will want eclipse, or vim, or jedit, or 
>netbeans, or QT tools, etc.).

So what?  The distro also installs stuff like nano and an inetd that
most people don't use.  Somehow, when I last looked (a few years ago),
Debian installed nothing that I use, except a shell and apt-get;
that's ok when I ask for a minimal install, but requiring 600MB for
that alone is a bit stiff.  Anyway, in the old days distros used to
have options that said "typical server", "typical desktop", "typical
development environment"; I have not seen the latter option for a
number of years.

And installing hundreds of packages to get a decent environment gets
old quick, even if each package is easy to install.

>> As for /opt, I don't know where that nonsense comes from, but it
>> certainly does not come from the original Unix.  Proper programs are
>> installed in one of the directories that users have in the PATH by
>> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
>> /opt (which indicates that the programmer is too lazy to make a
>> working "make install").
>
>You appear to be supremely confident that your own personal usage of 
>Linux, and your own (somewhat lacking and biased) view of OS history, is 
>/the/ truth and /the/ right way to do things.

Sure, comes from experience, not just with Linux, but also with other
Unices for about 29 years.  If you want to counter my point, you could
try explaining the benefits of /opt instead of making an ad-hominem
attack.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#20725

On 18/04/15 15:08, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 18/04/15 11:15, Anton Ertl wrote:
>>> Anyway, Unix may have the highest proportion of programmers, but it
>>> seems that non-programmers are the primary target of the Linux
>>> distributions these days.  E.g., neither emacs nor vi nor Eclipse is
>>> installed in Debian by default.  Or look at what programming languages
>>> are installed by default.  Only those necessary for running the
>>> scripts, no others.
>>
>> Most distros install a subset of commonly used tools, and then make it
>> easy for others to be installed.  There are vast numbers of tools,
>> editors, languages, libraries, etc., commonly used by programmers - it
>> would be ridiculous to install 2GB+ of popular programming tools when
>> even most full-time programmers won't need them.  (i.e., /you/ might
>> want emacs - but someone else will want eclipse, or vim, or jedit, or
>> netbeans, or QT tools, etc.).
>
> So what?  The distro also installs stuff like nano and an inetd that
> most people don't use.

Yes, but nano is provides an essential function - a simple command-line 
editor.  And it takes about 100 KB - as compared to eclipse at about 100 
MB or so.  Eclipse is useful to many programmers (I use it myself), and 
equally it is despised by many programmers.  But the cost (in terms of 
disk space, network download, etc.) is significant for those that don't 
need it - unlike the cost of nano.

> Somehow, when I last looked (a few years ago),
> Debian installed nothing that I use, except a shell and apt-get;
> that's ok when I ask for a minimal install, but requiring 600MB for
> that alone is a bit stiff.  Anyway, in the old days distros used to
> have options that said "typical server", "typical desktop", "typical
> development environment"; I have not seen the latter option for a
> number of years.

Some distros still have it (or are by their nature a "typical desktop" 
or "typical server", such as Linux Mint or Centos).

>
> And installing hundreds of packages to get a decent environment gets
> old quick, even if each package is easy to install.
>
>>> As for /opt, I don't know where that nonsense comes from, but it
>>> certainly does not come from the original Unix.  Proper programs are
>>> installed in one of the directories that users have in the PATH by
>>> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
>>> /opt (which indicates that the programmer is too lazy to make a
>>> working "make install").
>>
>> You appear to be supremely confident that your own personal usage of
>> Linux, and your own (somewhat lacking and biased) view of OS history, is
>> /the/ truth and /the/ right way to do things.
>
> Sure, comes from experience, not just with Linux, but also with other
> Unices for about 29 years.  If you want to counter my point, you could
> try explaining the benefits of /opt instead of making an ad-hominem
> attack.
>

Just a point here - if my post was an "ad-hominem attack" (which I don't 
think it was, and it was not intended to be), then so was your 
characterisation of /opt users as "lazy" and "nonsense".  So let us move 
past that.

In the beginning of unix, /usr was the place for site-specific or 
user-chosen software.  Gradually, due to the way disks and filesystems 
were often mounted, more and more of the standard or base files ended up 
in /usr.  People put their own software in /usr/local.  Then people 
started looking for a place to put software that would not interfere 
with system software (i.e., distro-provided software for Linux, in /usr) 
or software chosen, compiled and installed by users (in /usr/local). 
/opt became common as a distro-independant place to put things.

So on my systems, I have software from the likes of Atmel and Freescale 
in /opt.  This is software that came pre-compiled, and could have 
paid-for licences.  The tools are not on my path - nor should they be, 
as the compilers are specified explicitly in Makefiles as needed.  If I 
want a short-cut for starting an IDE, I put a symbolic link in ~/bin (or 
sometimes a bash wrapper).

Is it a perfect system?  No, there is no such thing.  But it works 
simply, easily and conveniently, and makes it very simple for me to 
distinguish between distro software and third-party software, and makes 
it simple for upgrading or moving to a new system.

[toc] | [prev] | [next] | [standalone]

#20756

David Brown <david.brown@hesbynett.no> writes:
>On 18/04/15 15:08, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> So what?  The distro also installs stuff like nano and an inetd that
>> most people don't use.
>
>Yes, but nano is provides an essential function - a simple command-line 
>editor.  And it takes about 100 KB - as compared to eclipse at about 100 
>MB or so.  Eclipse is useful to many programmers (I use it myself), and 
>equally it is despised by many programmers.  But the cost (in terms of 
>disk space, network download, etc.) is significant for those that don't 
>need it - unlike the cost of nano.

187KB, and it does not even have Emacs or vi key bindings.  I wonder
what it is doing with all that space, but it's certainly nothing I
use.

Looking at the popularity-contest results, some form of vi seems to be
installed more often than nano (it seems that there are people who
uninstall nano), so Debian could install vi in the first place.

Anyway, not installing a programmer's editor and installing nano
instead supports my claim that they do not target programmers.

name                  inst  vote   old recent no-files (maintainer) 
nano                 170116 32133 119241 18640   102 (Jordi Mallach)
vim-common           174062 59805 87555  26616    86 (Debian Vim Mai
vim                   67701 23297  36271  8105    28 (Debian Vim Mai
vim-tiny             169261 13839 120285 35040    97 (Debian Vim Mai
emacsen-common        54751 10282  37601  6821    47 (Rob Browning) 
emacs23-bin-common    16067  5231  10516   312     8 (Rob Browning) 
emacs23               13261  4400   8585   271     5 (Rob Browning) 
emacs24-bin-common     6512  3233   2460   819     0 (Rob Browning) 
emacs24                5696  2811   2135   750     0 (Rob Browning) 
emacs24-common         6521  1526   3820  1166     9 (Rob Browning) 
emacs23-common        16092  1392  14170   497    33 (Rob Browning) 
eclipse-platform-data  7092  1840   3736  1511     5 (Debian Orbital
eclipse-rcp            7249  1700   4112  1429     8 (Debian Orbital
eclipse-platform       6962  1628   3914  1414     6 (Debian Orbital
eclipse-jdt            6903  1185   5290   369    59 (Debian Orbital
eclipse-pde            6859  1184   5292   368    15 (Debian Orbital

>> Somehow, when I last looked (a few years ago),
>> Debian installed nothing that I use, except a shell and apt-get;
>> that's ok when I ask for a minimal install, but requiring 600MB for
>> that alone is a bit stiff.  Anyway, in the old days distros used to
>> have options that said "typical server", "typical desktop", "typical
>> development environment"; I have not seen the latter option for a
>> number of years.
>
>Some distros still have it (or are by their nature a "typical desktop" 
>or "typical server", such as Linux Mint or Centos).

Which one still has "typical development environment"?

>>>> As for /opt, I don't know where that nonsense comes from, but it
>>>> certainly does not come from the original Unix.  Proper programs are
>>>> installed in one of the directories that users have in the PATH by
>>>> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
>>>> /opt (which indicates that the programmer is too lazy to make a
>>>> working "make install").
>>>
>>> You appear to be supremely confident that your own personal usage of
>>> Linux, and your own (somewhat lacking and biased) view of OS history, is
>>> /the/ truth and /the/ right way to do things.
>>
>> Sure, comes from experience, not just with Linux, but also with other
>> Unices for about 29 years.  If you want to counter my point, you could
>> try explaining the benefits of /opt instead of making an ad-hominem
>> attack.
>>
>
>Just a point here - if my post was an "ad-hominem attack" (which I don't 
>think it was, and it was not intended to be), then so was your 
>characterisation of /opt users as "lazy" and "nonsense".  So let us move 
>past that.

/opt users are victims of their software providers.  Concerning the
characterization of the programmers, I stand by that; ok, it could
also be incompetence.  If a programmer does not provide a "make
install" or at least an install script that installs the binaries or
links to the binaries in a directory that is in the usual path of
users (such as /usr/local/bin), but instead says in the README that
the sysadmin should create such links manually, or that the users
should put the /opt/.../bin directory in the PATH, no friendly
characterization comes to my mind.

>In the beginning of unix, /usr was the place for site-specific or 
>user-chosen software.  Gradually, due to the way disks and filesystems 
>were often mounted, more and more of the standard or base files ended up 
>in /usr.  People put their own software in /usr/local.  Then people 
>started looking for a place to put software that would not interfere 
>with system software (i.e., distro-provided software for Linux, in /usr) 
>or software chosen, compiled and installed by users (in /usr/local). 
>/opt became common as a distro-independant place to put things.
>
>So on my systems, I have software from the likes of Atmel and Freescale 
>in /opt.  This is software that came pre-compiled, and could have 
>paid-for licences.  The tools are not on my path - nor should they be, 
>as the compilers are specified explicitly in Makefiles as needed.  If I 
>want a short-cut for starting an IDE, I put a symbolic link in ~/bin (or 
>sometimes a bash wrapper).

So the example you gave of using "gforth" to call
"/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" would not even work
for your setup.

>Is it a perfect system?  No, there is no such thing.  But it works 
>simply, easily and conveniently, and makes it very simple for me to 
>distinguish between distro software and third-party software, and makes 
>it simple for upgrading or moving to a new system.

I see no advantage over using /usr/local.

Upgrading: Get the new version of the software, do "make install".
Ideally the software installs itself with version numbers, so you can
also call old versions.

Moving to a new system: Just copy /usr/local to the new system (or
somesuch; you could also install the new system on a new partition,
and mount the /usr/local there).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web