Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

On 11/26/2018 4:44 PM, Neil Van Dyke wrote:
I don't know how Snobol dropped out of awareness.  I almost never 
heard of it in the MS-DOS, Windows, or Unix workstation circles, even 
before Perl, though occasionally you'd see an interpreter on a BBS or 
freeware/shareware list.


That's funny because it definitely was around.  I know for a fact it was 
on SunOS and Ultrix, and there was a BSD version on VAX.  In the micro 
world there were CP/M and Apple II versions.  MSDOS had at least 2 
implementations: SNOBOL4 itself, and a descendant language called 
"Icon"[*].  Icon later was ported to both Macintosh and Windows 3.



[*] an unfortunate name given the imminent rise of WYSIWYG user 
interfaces.  Icon was not a graphical tool - it was a script language 
and runtime.  The name "Icon" was a nod to SNOBOL's beginnings as a 
symbolic computation language.



The most memorable mention I recall was a grad student in the '90s 
remarking that (IIRC) Andy van Dam wanted to teach Snobol to 
undergrads.  This being funny in a "he might be right, but it's lol so 
random, and he wouldn't actually do that" kind of way. (AvD did lead a 
grad school class, around '95, to evaluate candidate languages for CS 
intro use.  We looked at many languages, including Java when it was 
called Oak, but I don't recall anyone championing Snobol.)


It's interesting even that someone would joke about that late. AFAIK, 
SNOBOL4 was only taught from the late 60's to early 70's. Like other 
things that work well, it was evangelized by its users.


I am not aware of any metrics on how many users it had, but given the 
size of the computing community in 1980, even a few 10s of thousands 
would have been considered phenomenal.  Unlike today where something is 
a failure if it's not on a million smartphones within 6 months.  



Could Snobol be another case study of a good technology that fell out 
of use, such as due to accidents of products or user bases separate 
from the innate merits of the technologies?  Lisp and Smalltalk and 
Prolog and Betamax people could sympathize. :) 


I am pretty sure that was the situation.


Are there any new lessons we can learn about adoption, or any lessons 
of linguistics?  (Maybe one of the best string-processing features of 
Snobol is a Racket procedure or syntax extension waiting to happen. Or 
maybe understanding the twist of fate of Snobol will enlighten 
"https://www.neilvandyke.org/racket-money/; as to why we're not all 
rich already. :)


Adoption?  Probably not.  Things become popular if they appear at the 
right time, work well enough, and get some publicity.  Perl (predated 
Linux but) was able to capitalize on the Linux craze, and crucially an 
O'Reilly book about Perl appeared just  a few years after the initial 
release.  When SNOBOL4 was first released, there were no micros or 
personal workstations, operating systems were proprietary, and nobody 
was writing books about computing.


Linguistics?  Maybe.  One of SNOBOL4's main uses was automated document 
analysis and translation.  Human languages are contextual, and even 
though vocabulary is restricted, it's likely that no CF tool will ever 
be able to faithfully translate [regardless of how much time or power 
you throw at it].  But SNOBOL4 made significant inroads because it's 
complex recursive pattern language was able to do hard things like 
identifying indirect objects, pronoun references, etc. - things that 
made analyzing text possible.


As for implementing SNOBOL4 in Racket, I would think it should be 
relatively easy.  After all, it has already been done in C, Java, 
Python, JavaScript, etc.  I certainly could do SNOBOL4 as a standalone 
implementation, but I have not yet grokked how to create (#lang ...) 
languages integrated into Racket - and that's the way it should be done.


YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[Neil Van Dyke]

I don't know how Snobol dropped out of awareness.  I almost never heard 
of it in the MS-DOS, Windows, or Unix workstation circles, even before 
Perl, though occasionally you'd see an interpreter on a BBS or 
freeware/shareware list.


The most memorable mention I recall was a grad student in the '90s 
remarking that (IIRC) Andy van Dam wanted to teach Snobol to 
undergrads.  This being funny in a "he might be right, but it's lol so 
random, and he wouldn't actually do that" kind of way.  (AvD did lead a 
grad school class, around '95, to evaluate candidate languages for CS 
intro use.  We looked at many languages, including Java when it was 
called Oak, but I don't recall anyone championing Snobol.)


Could Snobol be another case study of a good technology that fell out of 
use, such as due to accidents of products or user bases separate from 
the innate merits of the technologies?  Lisp and Smalltalk and Prolog 
and Betamax people could sympathize. :)  Are there any new lessons we 
can learn about adoption, or any lessons of linguistics?  (Maybe one of 
the best string-processing features of Snobol is a Racket procedure or 
syntax extension waiting to happen. Or maybe understanding the twist of 
fate of Snobol will enlighten 
"https://www.neilvandyke.org/racket-money/; as to why we're not all rich 
already. :)


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

Very nice recap.  +1.


On 11/26/2018 1:50 PM, Neil Van Dyke wrote:


* the alternative to Perl was usually C or early C++ (though extension 
languages like Tcl and Python were starting to kick around; but Tcl's 
main use was relatively easy GUI development, and Python was just a 
bare language without libraries when Perl already had lots); and


Minor addition:

At the beginning, Perl was used mainly for text processing and report 
generation.  It was only later as it gained a significant number of 
libraries that it developed into a more useful general purpose tool.


Early on, the (much) better alternative to Perl was SNOBOL4 - a pattern 
matching language based on context free grammar that was far more 
powerful than Perl's regular expressions, and already was well 
established long before Perl existed.  SNOBOL4 was developed in the late 
60's, and through the 70's and 80's, for many people it was the GOTO 
tool for heavy duty text processing and report generation.


SNOBOL4 was a portable virtual machine implementation.  There were 
versions available for most common platforms, including IBM PC, and 
there even was a C macro implementation that could be embedded and used 
anywhere a C compiler was available.


SNOBOL4 did not have built-in database access, nor did it really have 
libraries [but its scripts were composable], so when Perl came along, it 
had a minor technical advantage in its extensibility.  But typically 
SNOBOL4 would be used in pipeline fashion, receiving and transforming 
input, e.g., from a database query tool.  SNOBOL4's popularly spawned 
several enhanced descendant languages - SPITBOL, Icon, Unicon, etc. - 
that co-existed with early Perl, also featured library extensibility, 
and SNOBOL4's more powerful text processing ability.



Unfortunately, the better tool doesn't always win.
George


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[Neil Van Dyke]

George Neuner wrote on 11/26/18 1:07 PM:

Perl should talk ... [...] It's a mystery to me how it became so popular.


I bet George knows the story, but I'd like to tell it for the list, 
since I think this is relevant background, to people interested in 
practical programming languages research...


Perl, though I'd try not to use it today, actually has a proud history 
of being a god-like power tool on Unix, starting circa 1990.  Four of 
the reasons:


* a Perl programmer could wipe the floor, functionality-wise, with even 
with the most skilled Unix shell person (the kind who could avoid 
textual expansion/evaluation bugs in Bourne and Csh, and do things like 
relational database operations using only AT / Bell Labs and Berkeley 
shell tools);


* Perl was portable (there was a lot of variation among all the 
engineering workstation Unix implementations; plus there were 
VAXstations that you'd otherwise have to script in DCL, and DEC stuff 
was all interesting and solid, but a very different philosophy from 
Unix; Linux and the PC BSDs, and most MS-DOS and Windows stuff, were 
still underpowered toys);


* the alternative to Perl was usually C or early C++ (though extension 
languages like Tcl and Python were starting to kick around; but Tcl's 
main use was relatively easy GUI development, and Python was just a bare 
language without libraries when Perl already had lots); and


* Perl was especially well-suited to the needs of sysadmins, doing 
everything from very sophisticated and complicated operations, to quick 
little labor-saving scripts.


There was also a second burst to Perl popularity, when the Web started 
to emerge.  Up until then, Perl was the lightsaber of the sysadmin, plus 
a few software developers who knew about it, and liked to use it on the 
side.  But one of the earliest ways to do server-side dynamic Web 
content, in the early-mid 1990s, was with the CGI interface to the Web 
server, and Perl had one of the first libraries for that, strong string 
manipulation, and quick process startup.  (I did most of my CGI in Perl, 
and only one in C, because it needed the GD library for drawing a 
diagram, and Perl didn't yet have library support for that.  And a Perl 
CGI script is how I have prior art on Facebook, years before, and mine 
was scraping multiple university resources in real time. :)  Other 
libraries and frameworks and Web servers and such came along, but, for a 
while, Perl was almost synonymous with server-side Web stuff, because it 
was there first, and you could get it to do what you needed.


I agree that Perl was always gratuitously crazy, with its linguistic 
shortcuts and redundant forms.  (Today, a student could have a blast, 
implementing a `#lang perl` for Perl 4 or later, and getting all the 
syntax and semantics right.)  The cult-like pride behind "you can do 
that in a single line of Perl", and perhaps being proud of line noise 
appearance, might've fed that.  But it was easy to see why Perl became 
popular despite this.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

On 11/26/2018 11:40 AM, David Storrs wrote:
On Sun, Nov 25, 2018 at 4:16 AM George Neuner > wrote:



On 11/25/2018 4:11 AM, Bogdan Popa wrote:

Is there a way to fork(2) in Racket?

Unfortunately, no.  Racket is cross-platform, and Windows doesn't
have the concept of fork().


As a point of information, Perl's approach is to make things available 
and add a note saying "This doesn't work on Windows because Windows is 
weaksauce doesn't support it." It's a balance between giving the user 
capabilities and protecting them from making mistakes.


Perl should talk ... it's the bastard child of BrainF*ck and line 
noise.  It's a mystery to me how it became so popular.


Though I can appreciate the beauty of fork [after reading Bach's book], 
quite a lot of people thought fork was a stupid idea ... including the 
people, originally from DEC, who wrote Windows NT. Windows has evolved a 
bit since then, but internally you still can see quite a bit of 
similarity to VMS [which, like Unix, was very reliable and inspired 
legions of fans].



The guts of Windows are every bit of good as Unix ... it's the fluff 
Microsoft layered on top that is the problem.


I administered a mixed group of NT and 2K servers for over 10 years: 
running internet relay, DNS, file service, mail service, , source & 
document control, Sybase server, workgroup backup, and a pair of 
terminal servers hosting shared development tools.  In all that time, 
there were only 2 crashes, both due to failing hard drives. The servers 
were rebooted once a year just for the heck of it, and a few times over 
their lives to install or upgrade software.  Other than that, they ran 24/7.


Though I'm no longer dealing with Windows servers, I still know people 
who are.  Not kidding, Windows is VERY reliable as long as you avoid 
running too many Microsoft applications on it.


During that same period I was developing industrial vision applications 
on Windows.  I had multiple versions of Microsoft and Intel tool chains 
and SIMD libraries, etc. on my desktop, and I could lock up Windows with 
10 lines of code (still works, btw!!!). But MSWord would crash on me at 
least once a week - it gave me far more grief than everything else put 
together.


I'm still using a Windows 7 desktop that runs for months at a time. It 
gets rebooted only to install or upgrade software  [and I don't abide 
Microsoft's monthly update schedule - I consider OS updates if/when I 
need to do something else].  I still have Visual Studio, and Racket, and 
Python, and a few other things ... but I abandoned MSOffice for Libre 
long ago.


YMMV,
George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[David Storrs]

On Sun, Nov 25, 2018 at 4:16 AM George Neuner  wrote:

>
> On 11/25/2018 4:11 AM, Bogdan Popa wrote:
>
> Is there a way to fork(2) in Racket?
>
> Unfortunately, no.  Racket is cross-platform, and Windows doesn't have the
> concept of fork().
>

As a point of information, Perl's approach is to make things available and
add a note saying "This doesn't work on Windows because Windows is
weaksauce^H^H^H^H^H^H^H^H^H^H doesn't support it."  It's a balance between
giving the user capabilities and protecting them from making mistakes.



> George
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

On 11/25/2018 4:11 AM, Bogdan Popa wrote:
One way you might also solve this on UNIX systems is you could fork 
after listening on the socket. The file descriptor for the socket from 
the parent would then be shared with the children and so their accept 
calls would be "load balanced" by way of them all accepting 
connections from the same queue. This solves the problem without 
requiring SO_REUSEPORT (the disadvantage being that there's only a 
single kernel-level accept queue with this approach, whereas with 
SO_REUSEPORT each process would get its own queue).


Is there a way to fork(2) in Racket?


Unfortunately, no.  Racket is cross-platform, and Windows doesn't have 
the concept of fork().


George



--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[Bogdan Popa]

One way you might also solve this on UNIX systems is you could fork after 
listening on the socket. The file descriptor for the socket from the parent 
would then be shared with the children and so their accept calls would be "load 
balanced" by way of them all accepting connections from the same queue. This 
solves the problem without requiring SO_REUSEPORT (the disadvantage being that 
there's only a single kernel-level accept queue with this approach, whereas 
with SO_REUSEPORT each process would get its own queue). 

Is there a way to fork(2) in Racket?

On Sun, Nov 25th, 2018 at 10:51 AM, George Neuner  wrote:

> 
> 
> 
> On 11/24/2018 7:39 PM, Philip McGrath wrote:
> 
> 
>> On Fri, Nov 23, 2018 at 5:44 PM George Neuner < gneun...@comcast.net >
>> wrote:
>> 
>> 
>>> Multiple (identical) server instances running on the same machine can
>>> listen for connections on the same network port - an incoming client call
>>> will be connected to only one of them.  You only need to use different
>>> ports when services are not interchangeable [i.e. it matters which one you
>>> are talking to].
>>> 
>>> Process parallelism, in effect, can give you automatic connection load
>>> balancing on a single machine.  Using a separate load balancer in front
>>> technically is overkill for such situations, but it is a good design if
>>> you want to preserve the option to relocate your services to different
>>> machines.
>>> 
>>> 
>> 
>> 
>> 
>> I didn't know this, and it sounds useful! Unfortunately, this
>> functionality doesn't currently seem to be exposed at the Racket level.
>> This example program:
>> 
>> 
>> #lang racket
>> 
>> (provide launch-places)
>> 
>> (module+ main
>>   (launch-places))
>> 
>> (define (launch-places [port 8011])
>>   (define place-log-pch
>>     (let-values ([{in-pch place-log-pch} (place-channel)])
>>   (thread (λ ()
>>     (let loop ()
>>   (write-string (place-channel-get in-pch))
>>   (loop
>>   place-log-pch))
>>   (define workers
>>     (for/list ([n (in-range 0 2)])
>>   (place/context p
>>     (define (place-log msg)
>>   (place-channel-put place-log-pch
>>  (format "Place ~a: ~a\n" n msg)))
>>     (parameterize
>>     ([error-display-handler (λ (s v) (place-log s))])
>>   (place-log "started")
>>   (define listener
>>     (tcp-listen port 4 'reuse))
>>   (place-log "created listener")
>>   ;; don't let listener be gc-ed
>>   (tcp-accept listener)
>>   (place-log "ended")
>>   (apply sync (map place-dead-evt workers))
>>   (for-each place-kill workers))
>> 
>> 
>> prints the following output on both Mac OS and Ubuntu:
>> Place 0: started
>> Place 0: created listener
>> Place 1: started
>> Place 1: tcp-listen: listen failed
>>   port number: 8011
>>   system error: Address already in use; errno=48
>> 
>> 
>> It looks like the `reuse?` argument to `tcp-listen` corresponds to
>> `SO_REUSEADDR` rather than `SO_REUSEPORT`. That's consistent with what
>> `udp-bind!` explicitly says it does, and its the only thing I can see
>> happening in the implementation ( 
>> https://github.com/racket/racket/blob/master/racket/src/rktio/rktio_network.c
>> )
>> 
>> 
>> 
>> It seems like this might be a useful feature in Racket, but I'm not sure
>> of what would be needed to expose it in a good way. In particular, some
>> quick Googling revealed that there are some portability considerations,
>> which I haven't fully digested yet ( 
>> https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
>> ).
>> 
>> 
>> -Philip
>> 
>> 
>> 
>> 
> 
> 
> 
> It's not working because the places in this code are OS threads in the
> SAME process.  You need to start separate processes:  using *dynamic-place*
> targeting localhost, or using *system* , *process* , *subprocess* , etc.
> 
> AIUI  'reuse?'  sets both  SO_REUSEADDR  and SO_REUSEPORT.  But a single
> process can't open the same port twice.
> 
> George
> 
> 
> 
> 
> 
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

Paulo Matos recently announced a library called "Loci" that allows for
using mulitple processes with much the same API as places.
https://pkgs.racket-lang.org/package/loci


I haven't tried it, but it looks interesting.

George

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

On 11/24/2018 7:39 PM, Philip McGrath wrote:
On Fri, Nov 23, 2018 at 5:44 PM George Neuner > wrote:


Multiple (identical) server instances running on the same machine
can listen for connections on the same network port - an incoming
client call will be connected to only one of them.  You only need
to use different ports when services are not interchangeable [i.e.
it matters which one you are talking to].

Process parallelism, in effect, can give you automatic connection
load balancing on a single machine.  Using a separate load
balancer in front technically is overkill for such situations, but
it is a good design if you want to preserve the option to relocate
your services to different machines.


I didn't know this, and it sounds useful! Unfortunately, this 
functionality doesn't currently seem to be exposed at the Racket 
level. This example program:


#lang racket

(provide launch-places)

(module+ main
  (launch-places))

(define (launch-places [port 8011])
  (define place-log-pch
    (let-values ([{in-pch place-log-pch} (place-channel)])
  (thread (λ ()
    (let loop ()
  (write-string (place-channel-get in-pch))
  (loop
  place-log-pch))
  (define workers
    (for/list ([n (in-range 0 2)])
  (place/context p
    (define (place-log msg)
  (place-channel-put place-log-pch
 (format "Place ~a: ~a\n" n msg)))
    (parameterize
    ([error-display-handler (λ (s v) (place-log s))])
  (place-log "started")
  (define listener
    (tcp-listen port 4 'reuse))
  (place-log "created listener")
  ;; don't let listener be gc-ed
  (tcp-accept listener)
  (place-log "ended")
  (apply sync (map place-dead-evt workers))
  (for-each place-kill workers))

prints the following output on both Mac OS and Ubuntu:
Place 0: started
Place 0: created listener
Place 1: started
Place 1: tcp-listen: listen failed
  port number: 8011
  system error: Address already in use; errno=48

It looks like the `reuse?` argument to `tcp-listen` corresponds to 
`SO_REUSEADDR` rather than `SO_REUSEPORT`. That's consistent with what 
`udp-bind!` explicitly says it does, and its the only thing I can see 
happening in the implementation 
(https://github.com/racket/racket/blob/master/racket/src/rktio/rktio_network.c)


It seems like this might be a useful feature in Racket, but I'm not 
sure of what would be needed to expose it in a good way. In 
particular, some quick Googling revealed that there are some 
portability considerations, which I haven't fully digested yet 
(https://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t).


-Philip




It's not working because the places in this code are OS threads in the 
SAME process.  You need to start separate processes:  using 
*dynamic-place* targeting localhost, or using *system*, *process*, 
*subprocess*, etc.


AIUI  'reuse?'  sets both  SO_REUSEADDR  and SO_REUSEPORT.  But a single 
process can't open the same port twice.


George

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.