On 20/04/2016 10:02, Liam Proven wrote: Extreme Mailing What is the most unusual place you have sent mail from?

On Wed, Apr 20, 2016 at 01:32:01PM +0200, Jonathan Katz wrote: For remote mailing I prefer i vt terminal and a microwave link: https://youtu.be/r6NuDcemRsM /P

I don't think this is particularly strange, but back in college I had UUCP running on my Amiga 1000, and I set it up to dial in to the Sun SPARCstation IPC (IIRC) sitting on the computer support help desk at UCI. I was one of the help desk staff, and had permission from the bosses to do it. I had to hack up the sendmail.cf on that system to route things properly, and back then there were no m4 macros to help out. Raw sendmail.cf hacking was a harrowing experience! I think I had my Amiga dial in to poll for email every 10-15 minutes, and I hacked the code to blink the power LED when I had new mail waiting. That way, I could tell at a glance if I had new mail even with the monitor off. One of my friends who also worked the helpdesk also dialed in the same way. The pay was nice, but the real reason I wanted the job was because of perks like a key to the machine room and access to computers unbound by such silly limitations as process and disk space quotas, or not having the root password. I could mount my own tapes and pull my own printouts off the line printer (though I'd naturally use the Imagen laser printer instead). When it came time to do some simulations of a utility-scale power transformer design for a power engineering class, I didn't need to fight over Sun 3/60s in an engineering lab like most of the other students. Nope, I ran my sims on the Convex C-240 supercomputer! They probably would have run just as fast, if not faster, on the Suns since I wasn't doing any vector math, but it was a "just because I can" sort of thing. Once, while our boss was away on vacation, my friend and I rolled a decommissioned VX-11/780 down the hallway from the machine room and crammed it into his very small office. We powered up some blowers to make it seem like it was on, and also put an unguarded DEC Correspondent on his desk, on which we typed stuff to make it look like we were trying to boot the VAX. I wish I was on shift when he arrived at work! I'm told that his reaction was delightful. Another later boss, in a different branch of the same computer support department, once got similar treatment with a TU-77 tape drive. That wasn't my doing, but I like to think I was an inspiration. Boy, do I wish I had that 11/780 and TU-77 now! I think they were slated to be sent down to Mexico or something like that. Speaking of the C-240, I personally found it very useful when I had a graveyard shift computer operator job. The machine room had its own A/C, and the main building A/C would be shut off overnight. The building A/C would turn back on at 6AM to get the computer science building ready for morning classes at 8AM. With the sudden cooling surge, the computer room temperature would plummet, right at a time when my metabolism was already pretty much shut down from the fatigue of staying up all night. When that happened, I would often curl up in a shivering fetal position on the floor right behind the C-240's power supply cabinet, in the path of its blower exhaust. I experimentally determined that was the warmest easily-accessible area in the machine room. Good times, good times. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

My first experiences with internet mail would have to qualify as the weirdest. My family gained access to the internet in 1988. We'd dial into the NMSU terminal server (my mother was a professor there) and connect from the terminal server to an S/390 running VM/ESA and do an IPL CMS to get to a reasonable shell that afforded access to e-mail, the XEDIT editor, and the Charlotte web browser. The challenge was that for the first few years, we didn't know we needed a 3270 emulator, so CMS would go into a strange mode that only somewhat worked... If you made a mistake in typing, you had to start all over. But, I ultimately figured out how to get a SLIP connection going from the terminal server and use a proper TN3270 client to access the mainframe instead of ProComm Plus. It wouldn't be until 1994 that the university allowed access to the public internet directly through SLIP or PPP. I want to set up a VM environment on Hercules to relive those times, now that I am light years more competent. -- *John P. Willis* Coherent Logic Development LLC M: 575.520.9542 O: 575.524.1034 chocolatejollis38 at gmail.com http://www.coherent-logic.com/

I think I remember slirp... didn't that somewhat emulate a SLIP link through a shell account? That's another thing I remember and miss from those days... your average ISP would provide NNTP and UNIX shell accounts, as well as a few megs of space to put up a personal web site in ~/public_html.

On Thu, 21 Apr 2016, John Willis wrote: Yes. It was (and kinda still is) awesome. The coolest thing about it is that, unlike using PPP or SLIP, you don't need valid IPs as endpoints. Slirp was like a poor mans dynamic one-to-many NAT before there was such a beast. That was a great thing when you were a college student without any juice to get an IP from the IT beast that ran the school. Yep. I miss that too. I used to run such an ISP in the 90's and we did exactly as you say. We also ran a finger servers everywhere (and no, not one with a bunch of security problems). People used to use that in cool ways, too (bots, cool services, vending machine interfaces, etc..). <rant> The simple fact is that most folks are too apathetic and ignorant to care about such things anymore. The Internet is a large, but still textbook case of what happens when you let business-weasels in on something good. They "monetize" it and turn it into a combination strip-mall, casino, theatre, porn-shop. Of course, the Internet wouldn't be what it is without said weasels, (certainly not as large) but I think I'd be pretty okay with that. I'd be okay without 80% of Internet traffic being video, too. I guess that makes me a curmudgeon (but I've always hated TV and I resent the forces trying to morph the Internet into on-demand cable television). Yea yeah, I know I'm just peeing in the wind to say it, but there it is. I remember when computers used to come with a programming manual and schematics for the machine, too. Even mid-level stereo equipment would often come with schematics. That's because those folks (the generation before me, I'm a gen-X unit) had a significant population of people who cared about such things and could run a soldering iron. Just like there didn't used to be any such thing as Computer Science. Ie.. you learned electrical engineering (ie.. how the darn chips themselves worked, first) or some other technical discipline then applied that to computing. Now, most colleges want to teach you Java and call you a computer scientist. We get college grads all the time and I'm shocked to see how little they've actually been taught relating to computing. They are marginally more useful than high school kids and that's only because they don't show up quite as late for work. I'm not saying everything was perfect in the 80's or 90's. I mean, some CS professors in the 90's were teaching Oberon, LISP dialects, or Smalltalk. Then if you ever uttered the (completely true) phrase "not commercially viable" they'd launch into some diatribe about how these languages taught you some kind of special spiritual meta-programming that'd ultimately path the path for you to become some kind of code-God (like them?). That is, as long as you bought their 18th edition $160 book (only at the college bookstore). So, no, things were never perfect, and people had to try and do work with Windows for Workgroups 3.11. :-) Point is, I don't have blinders on, but there are *reasons* why I'm nostalgic. Just like I'm nostalgic for the days (before my time) when a person could earn interest on their savings. I'm not saying things were perfect, but some aspects of the past were definitely better. </rant> -Swift

On Thu, 21 Apr 2016, John Willis wrote: Me, too! That was a great feature. I'd finger '@' some server that my classmates used and then use talk or ytalk to figure out how to do our homework etc... People who didn't want to participate could just turn off talk requests. Well said. I feel the same way. First class servers talking with other first-class servers. This has been lost, now. If you want to "run a server" your ISP hears a cash register opening and you'll need a "business" account. It's so far away from the vision you describe well. It's so important. Most people didn't feel the loss, but guys like you and I won't let go of that vision so easily (for all the good it does us). However, they are *memories* now, and that's sad. It's like remembering a great oak circle in an old growth forest before they cut it down to put up condos and a Starbucks. Folks who live there love the Starbucks, and would recoil in horror at the idea of letting it all go... but we remember. Yes, exactly. "Back in the day" I felt like nothing would ever be "lost" on the Internet. As bandwidth and storage got cheap, I figured access would increase, not decrease. Now, I'm noticing that *plenty* of stuff is getting lost. I'll admit I even cringed when I saw Geocities dying. Yeah it was a cheesy service but, for example, I have a friend who is a master gunsmith and put all kinds of excellent info on a site he made. Now it's gone and you can't find that some of that info via a search anymore at all. That phenomenon seems to be picking up speed. It reminds me a bit of a book I read called "The Media Monopoly" by Ben Bagdikian. He talks about how even small towns used to have 2-3 newspapers with local news. Now they have none and the regional big-city paper only spouts syndicated news. So, I guess I was naive. More money and resources pouring into something don't mean better access to the "consumer". I've often thought the same thing, but now I wonder. Is it NAT keeping everyone suppressed behind dynamic translation or is it more that 80% of the people on the net are just consuming media and since they don't clamor for equal "real" IP access, the ISPs simply don't care about that. I still hate Network Solutions and all the NICs for that, too. However, it was bound to happen one way or another. The math (internet population to ipv4 availability) doesn't work. So, I guess I should get over it. I used to give presentations on IPv6. My talk was very skeptical of the potential it promises and even more suspicious of all the QoS features that look awfully like what corporates want to make sure "free" content is basically slow and useless. I used to have a healthy dose of fear that IPv6 would make the situation a bit worse because of how ISPs would use the internal features. However, nowadays despite all kinds of pronouncements from Cisco and other network "geniuses" that "we have to do it! There is no choice! It's coming tomorrow. It's already widespread!" If I had a BS flag I'd throw it. The proof of their consummate failure to get IPv6 into any kind of widespread use is very evident to those who look. There is a discussion of this on Reddit that pretty well hits the mark. Even the pro-ipv6 folks say things like "Oh come on, I've been running it for years [dual stack] and we have 25% of our users on it already! It's not a failure" Oh Ohhhhhkhay. https://www.reddit.com/r/networking/comments/2w5u9o/biggest_failure_in_it_i… Remember the old cry of "Information wants to be free!" ? It still rings true.... in the wilderness. I'd do the same thing if I wasn't such a tightwad or didn't have friends that did as you do who let me host with them. It's definitely very sub-optimal and expensive for no good reason. Cool. Is it over wireless or how do you do it? Bless you sir. I wish I lived in your hood, then. Ha! Good! Yes! I used all those as well. I wasn't a big gopher user but I logged many hours with archie and veronica. I would mention ICB, but since IRC is still going strong, I certainly won't whine about that. I still celebrate the vitality of the current IRC nets. I agree, and it wasn't just individual blockheads, it was bad actors and corporations in a gold-rush mentality too. There was more than just an economic crash in 1999 it also represented a crashing of what the Internet had represented up to that point. It seems to be a process much like gentrification of a neighborhood. The same stuff has happened to some unnamed OS projects, too. The leader talks about minimalism and technical community in 1993 then flips a b**** and presides over massive mega-daemons running systems with binary logs and gobbling up as many small-is-beautiful services as possible. Heresy. *nod* Especially when you compare it to the present state of the art. I suppose if you were 19 you might point to social media and "interconnectedness" that comes from that. However, I really don't feel it when the corporate overlords run the services with the NSA breathing down our necks. The idea was to have a truly "peer to peer" system where the peers are first class citizens with equal access. Remember the "Morris Worm" ? That's a good example. Yeah, it was self-replicating code but it did.... nothing. Any negative side effect was just from the rapid spreading and system resources it took. Nowadays, folks create viruses that encrypt and/or destroy the target for ransom the minute they can write 3 lines of code in Visual Basic. The level of malice and thuggery have gone way up. ... and it opened up so many possibilities. Look at what that and a low price did for the C64. It's "scene" is still somewhat healthy with so many loyal fans. I never owned one and don't know that much about them, but I respect those folks. ... or nothing but a notecard saying "Go online to http://kindergarten-crap-docs.com/hardly_anything for documentation!" I love the excuse, too. "It's better for the environment!" Ugh. That's great news if you are a blood sucking lawyer. However, it's not so good if you want to use your compiler without fear or stepping on a legal landmine buried on page 31, subsection 8, paragraph 4. I dropped out in my 4th year for the same reason. I got sick of listening to incompetant failures (with a few exceptions) talking about failed ideas and failed languages while I watched my friends making 6x the income with no degree or training at all (late 90s). It was time to strike while the iron was hot. I work with people who had great academic experiences, but then again they went to good schools - some of the same ones I was accepted to but wasn't willing to rack up 250k in debt to attend. I don't talk to anyone over 50 about college/uni - most of them have no idea what it's like now and spout establishment BS. Only my younger friends and younger brothers understand this I talked my brothers out of philosophy and history majors into ChemE. They graduate next year and they may be the only ones amoung their classmates finding jobs, too (according to them, not me). Same here. I do some woodworking and when I go to classes, say to learn dovetailing, the #1 thing I come away glad to have learned was the tips and tricks from the guys who've already mastered it. Plus, when you sit down and read a text book or manual, you aren't doing it to pass a test - you are doing it to master the material. I found out to my sorrow that those aren't the same things. So, now I focus only on the latter. Fortunately, so did I. I guess we do catch some breaks in life :-) Thank goodness for the BSDs, or I'd be even more cynical. There is some good left on the net, but it's sadly not in the same places anymore, and I now know there is no guarantee anything will go on untarnished forever. That's just a process of maturing, I suppose. Thanks for that post. Very cathartic. Glad I'm not the only one. :-) -Swift

On Wed, 27 Apr 2016, Mouse wrote: Heh, I'm guessing you've been doing something like that for a very long time. I remember "Der Mouse" the Sun god from very early days of the net, and I suspect you are one in the same. As far as CIDR goes, I agree. I'm glad CIDR exists but sad that it needs to be this way "normally". What I've often wondered is why there are so many IT people with the same sort of laments and we haven't all collectively built our own networks over wireless ? I remember when a friend of mine who was a HAM showed me his 1200 BPS packet radio setup. I was blown away and I could envision an army of radio geeks interfacing together to form a civilian Internet (and this was before the Internet caught on). I had the same thought when Lucent Wavelan cards and subsequent wireless devices caught on. I figured we could network an entire city together using a mix of directional antennae for the long runs, and omnis for the distribution layers. Then inter-city traffic could be done with either long range elevated yagis or land lines paid for by the "collectives" in each city. Perhaps Karl Marx might have shared my vision, but the "real world" didn't. I wonder why... FCC rules too strict? The tech isn't as robust as I thought? Hidden operating costs I'm not thinking of? I'm naive, I guess. I thought we'd all be running our own little "cells" right now, not fighting for scraps of bandwidth from *horrified gasp* the dirty monopolistic cable companies and lyin' cheatin' phone companies. Meanwhile folks in places like Korea are laughing and using Fiber or Ethernet and paying pennies on the dollar compared to options we've got in the USA. -Swift

On Wed, 27 Apr 2016, Mouse wrote: It's not an overstatement to me, sir. You would probably be very surprised if you knew how many fixes you've helped me out of. I don't know how many times I'd come across one of your posts on Sunhelp or elsewhere that'd provide the key bit of info I needed etc... So, thanks! Not to mention that IIRC, you've carried the torch (magnesium flare in your case) against top posting for as long as folks have done it! Heh, that reminds me of living in Norway and learning to speak Norsk (bokmal). I'd sit and watch TV (as long as it was in Bokmal, and most was in Nynorsk) in Norsk with English subtitles. Then I'd flip over and watch English shows with Norsk subtitles. Then I'd unleash myself upon the small town folk in Moss, Norway and they'd be either greatly amused or occasionally horrified by my grammar (but they were always cool and helping me learn). I slowly got better by talking to older folks. They spoke slower and were more patient with me (but I'd still often butcher things or say things they thought were hilarious). I wonder if there would ever be a chance of having something like a set of digital-only FRS frequencies but on a bandpass that's got better range (or one with perhaps better penetration). My guess on that is that those are so valuable that the FCC (and industry) wouldn't want to risk having untrained apelets near their frequencies. I'm with you, Mouse. However, perhaps if it wasn't enough bandwidth for video and the masses already got satiated via Comcast + Netflix, maybe.... just maybe they'd stay away. Bah... who am I kidding, they'd just adapt the next gen of phones to hork whatever they could from the "civilian internet" frequencies if they were available. You'd be stuffed to the gills with facebook and twitter. Ahh... despair. Ewww. I didn't think that. The pedos start freeloading and then the man comes down on the operators to satisfy the merchant outcry "Will no one rid me of this troublesome free network!" (to misquote Henry II). *sigh* Yep. -Swift

It was thus said that the Great Mouse once stated: Just look into the political machinations of what was known as FidoNet to see how this could end up. -spc ("The fighting was intense because the stakes were so low ... ")

Why, hello, 1:138/142! 1:305/1 here!

On Wed, Apr 27, 2016 at 10:07:34AM -0700, geneb wrote: [...] Pardon my ignorant question but is there a place on the net where I could read some more about it? Or maybe it is short enough to explain here? And on-topic: I have some memories about reading my email by dialing up special account on my uni (decades ago) with 14.4k ISA modem under DOS, without hardware error correction. Hw e. c. was too costly for me and I naively believed I could get away with cheaper modem. Phone lines in Poland at that time (mid 1990ies) were rather shitty - apart few end users on same pair of wires (or something like this), which reduced available bandwith even more. So I dialed up that account, choose a system to log in and logged in, typed mailx, read quickly quickly quickly. If I was lucky, I could read what I wanted (short mail from fellow student about project progress and the like) before some electric crack sent my modem into stupor. Sometimes it did not disconnect properly and I had to manually pick up a phone to help it. I believe I used... control software that came with modem, if memory serves. It allowed me to actually see a stream coming from the modem. Ugly, some characters mangled. Was meant to dial BBSes. ATDT and off we go. Or on. Later on, my troubles somehow vanished because I learned how to use ppp monopolistic operator (who thus became country wide ISP). Much better. Hangups were very rare even with the same cheap modem, even if bandwith was shared with few neighbors... I disliked them anyway because they charged for every two minutes, no night tariffe, no local tariffe, nothing like this. Linux was a real blessing at that time [1], a natural upgrade path for someone who got a lick of multitasking on Amiga and upgraded to university SunOS workstation (with short episode on VAX, where I used to grab two neighboring terminals to edit on one and compile on another). I used to amuse myself about poor folks working at PC computers, when general Failure prompted them to abort or retry, or if they dared so, to fail. I have also bought me a better modem, external Zoom 56K, but even this one could not perform at maximal speed because of sharing wire, again. Few years later I took revenge on my telecom and switched to ADSL, 256kbps. It is 30Mbps now, after a series of upgrades. Or maybe 60Mbps? I somehow do not care so much anymore... Iso images come down the wire really fast, though. Now, thanks to double NAT (one in my router, one in theirs and third one somewhere nearby, if I read traceroute etc correctly) I do not think about running any services locally. Besides I believe it would have been great PITA and mostly done for showing up, because I do not even have a website (or anything justyfing setting one up). I miss gopher and archie, used them a lot back in days of modem (but not when dialing up, obviously). I also miss internet without javascript and with manually written pages optimized to load fast. A new strange, or normal, way to read stuff is now in terminal emulator, mutt over ssh. Nothing really strange. It was much stranger when I could not ssh (for whatever reason) and had to check mail via webmail. I am a compulsive email reader and use to hoard few thousand a month (around 10 if that interests anybody) - I do not think my computer ever heard so much swearing as during those long moments of waiting for server to show me sorted list of my emails... [1] However, given how things evolve, I somehow wish I tried BSD. I became so entrenched into Linux, that migration is a not so trivial adventure. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com **

That's interesting I had a FidoBBs back in 1983 No 33 Written by a guy called Tom Jennings in C. I had a BT modem type 2B (about the size of a small suitcase) I modified it to auto answer. In addition it would dial out at 03:00 to exchange mail at 300baud There was a version for DEC Rainbow and I was working for DEC at the time. I asked if i could have one to replace the VT100 on my desk and try out any software. My boss said "sure - get a couple nobody wants them any way" I trot off to the stores and ask. They say Oh yeah there's load of pallets of them over there. Promotional stock - nobody wants them no DEC operating system. How many do you want? he asks Two says I. He says I'll go and get the fork lift. Er no - not two pallets full - just two boxes !! Rod Smallwood On 01/05/2016 03:43, geneb wrote:

On 2016-Apr-30, at 9:05 PM, Rod Smallwood wrote: Tom was on this list, up until somewhere ~ mid-2000s AIR. http://sensitiveresearch.com/ http://worldpowersystems.com/ . . from his resume: 1984 ? 1995: Fido Software (d/b/a), author Fido/Fidonet software

Not necessarily. You can do a lot better than linear search for route lookup. That can be done with non-contiguous subnet masks too (I remember reading a paper from 30ish years ago on that), but it takes less space -- fewer lookup table entries -- if the subnet masks are contiguous because then each subnet is only one numeric range rather than several. I think the main argument against non-contiguous masks is that it's a feature without a purpose, and a popular source of bugs. paul

From: Swift Griggs Sent: Thursday, April 21, 2016 9:11 AM Yes, and if you'd actually paid attention to what they were teaching you, instead of whinging about commercial viability, you would probably be better for it, especially the Lisp (although by the period you name, most of the fun was gone, with Common Lisp and Scheme as the two surviving dialects). Tell me about having to get work done on a 12K 1401, and maybe I'll listen. In the mean time, get off my lawn, kid. Rich FTHI: ;-> ;-> ;-> ;-> Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

Aye. I agree with you right down the line. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 04/22/2016 07:42 PM, ben wrote: Yeah, me too, though I have a thin client and old modem connected to the line to screen out junk calls. My lovely spouse owns a mobile phone, but it's just that, no smarts about it. If someone wants to text me, they can use my GV number. That puts us in the 9% of the industrialized world's population that doesn't use mobile phone, according to what I've read. --Chuck

On 04/25/2016 09:38 AM, Liam Proven wrote: Since FPC (Free Pascal Compiler) has been developed on Linux, maybe Pascal could have a resurgence. I used it to port a couple of my programs from (Ughhh!) Borland Turbo Pascal for Windows to Linux, and it was a surprisingly painless job. The only thing I notice is the error messages look exactly like Borland error messages on DOS. (Error 132 at 1B7F sort of thing.) Jon

On Mon, 25 Apr 2016, Chuck Guzis wrote: Well keep in mind that given that error, you could stick that address into the "Find Error Location" of the IDE and it would drop you right on the line of code that triggered the error. Check out Lazarus for doing cross-platform GUI applications. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!

On 04/25/2016 12:42 PM, geneb wrote: Yes, does that work with FPC on Linux? Jon

On 04/25/2016 12:30 PM, Chuck Guzis wrote: Linux compilers usually have decent diagnostics at compile time, and at least describe the error a bit at run time, rather than give an error code. I have no idea whether gdb will give any help on a run time error in a FPC program, but I have a funny feeling that they haven't linked in the requires stuff to do that, just from the message. I have debugged some c and c++ programs with gdb, and while it is a tad cryptic, it is quite powerful, you can examine variables and pointers and track down what is wrong. Since I had working Pascal programs and was just porting, I worked through the few errors pretty blindly, but wouldn't want to do that with a new program. Jon

I think it demonstrates that quoting the initial number of search results that Google returns is pretty unusable for any purpose. I only get 209,000 results. However, if I take Google at their word and page through them, when I get to page 29 (and only then), they finally admit that the number of results is more like 282. Along the way, there are some interesting matches like these: Download lagu 2ollux 2peak2 two you (ugh..my lisp sucks) Mp3 ... if you have a lisp... you cant say lisp... which sucks - Tickld Old Earl comment saying Casey Veggies Sucks ? Kanye West Forum ... 'Grey's Anatomy' Season 11 Recap: Maggie Tells Meredith They're ... @metalmouth25 Instagram photos | Websta (Webstagram) Frontal Lisp, Missing Teeth, and Thumbsucking ? Speech Pathology ... Your Tournament Sucks - Forums - World of Warcraft - Battle.net Scorpion is the latest TV show to do us nerds a disservice ... Urban Dictionary: Thisp Vince McMahon Reportedly Furious With Byron Saxton At RAW ... David Leadbetter to be fired by the Wie camp - GolfDiscussions A Current Affair's Leila McKinnon reveals lingual braces are behind ... Leila Mckinnon on her lisp. - Mamamia Encyclopedia of Health - Google Books Result Living with a lisp! | Latest News & Updates at Daily News & Analysis How To Break The Finger-Sucking Habit - Circle of Moms Is HGTV's Flip or Flop real? What Tarek El Moussa and Christina El ... Breaking the thumb sucking habit - BootsWebMD The Alpha's Protected Mate - Society Sucks - Wattpad Chie's new voice - Persona 4 Golden - Giant Bomb Popular bands that were terrible live | Steve Hoffman Music Forums Pennywise Help? [Archive] - Offspring.com Forums Orthodontic Sucks - I got a bite plate =o - PlayStation? Forums Why "After Earth" Is A Disaster - Business Insider Regards, Peter Coghlan.

On 25 April 2016 at 19:00, Swift Griggs <swiftgriggs at gmail.com> wrote: Yes. Because I was a support guy, and now am a writer, not a programmer. I have been researching programming languages and operating systems for decades now. The #1 problem of the IT industry is not any language, not processor design, not software or OS design. It's culture. Computers are built by people, and software for them is written by people. And as people, we live in cultures. Some things are cool, or desirable, or trendy. Some things give quick results, or are fun, or are inherently fast but risky and unstable. Others are hard, or are from the wrong college or company or country, or need too much up-front effort, or are slower but safe. And consistently, for decades, technically-illiterate managers have chosen to spend money on things that are cheap but quick, that give quick and dirty fixes. As a result, what we have today are the descendants, not of the best computers we have developed, but of the quickest-and-dirtiest lash-ups that could be made to work long enough to get through a sales demo. As a result, there's been a mass-extinction event of actual good code written by smart people who defy convention. Instead, we have a very small number of architectures and OSes, and layered on top of these unsound foundations are a profusion of tools which try to piecemeal fix the problems of the layers underneath -- and inevitably failing. But that's what we use, and so people choose sides and mock the other side. Unix people mock Windows people, and vice versa. Perl people dislike Python, Python folk don't see the need for Ruby. C types look down on all of them and desperately play down the stories of buffer overflows and stack smashing. And the industry is now huge, much comprised of people trying to fix the screw-ups of others in other places. Massive amounts of code and resources are devoted to keeping unstable stacks of unstable code in unstable languages more or less standing and running, at least in aggregate. Swift, you have provided a superb example of this mockery. And now you've been called on it, you are, in natural human fashion, lashing out in return. It's natural, it's human, and it's exactly why we have the stinking pile of crap that we do today instead of tools that actually work. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On Wed, 27 Apr 2016, Liam Proven wrote: Well, that's mighty big of you Liam. You are clearly a brilliant guy with a storied career and bristling with skills I only wish I had. As I read through your post here, I also got a lot more grit and understanding of why folks get as irritated as they do when I associate my bumbling college profs with something like LISP. It's silly of me to associate a language with a group of people. It's human, but still not very bright of me. LISP certainly has a lot of smart people advocating for it. It seems to represent a lost ideal or paradigm to them and it's I can see it's nasty of me to step on that, even if that's not my direct design to hurt them. I share your lament. One thing that also keeps jumping out at me over and over is how I meet people with the same kind of experiences you describe and they are often much more skilled and better critical thinkers than folks I know from my generation or younger. Don't get me wrong, there are plenty of young shining stars, but they just don't seem to occur with the same frequency. I have surmised that I am standing on the shoulders of giants going all the way back to folks like Grace Hopper, and that it's more and more difficult to grow in this field in the same way as the "old timers" (which for me is anyone who worked in the industry before 1989, I realize it's all relative). All "you guys" seemed to start out with math or EE background and filling in the CS parts seems to be trivial for you. I look up to your generation, believe it or not. I'm a bit sad those never caught on in the states. They are neat machines. For me, as a teen in the 1990s. I associated Unix with scientists, engineers, and "thinkers" in general. I'd walk into somewhere to fix a monitor or printer (I was a bench tech for a while) and the Unix guys wouldn't want me near their stuff. They could fix it themselves and they didn't want some punk kid who knew MSDOS to touch them. Meanwhile all the people I didn't respect (PHBs and other business-aligned folks) used beige boxes running DOS. I knew I was in the wrong place. Wasn't that kind of true, though? I've heard it said "C is nothing more than a macro assembler". I'm a C programmer as you might expect. I'd heartily agree. However, being a C programmer I also see C's warts. It's not big on syntactic sugar, but it does get the job done in a straightforward and pragmatic way. I do plenty of OO in other languages, but I still prefer procedural & structured coding techniques most of the time (as long as it effectively solves the problems). However, I'd reach for an OO language or heavily abuse callbacks in C if I needed to do a simulation. I still like to show non-coders how all these OSX library calls often *still* start with "ns" (next step). It reminds me of the famous statement "Those who do not learn from Unix are doomed to re-invent it... poorly." Windows 10 inclusion of bash seems to me to be a white flag on the part of Microsoft saying "You guys were right." Especially after pushing Powershell so hard. Of course, I'm sure the devils advocate would say "It's just a greater diversity in a massive constellation of functionality in Windows" A very weird one. Most of my Unix zealot friends use Macs now. I still use the console :-) If I must, then I'll use fluxbox in X11 on top of NetBSD. Go VMS. I hope VSI can pull it off. I also hope they change their licensing terms to be less draconian. IMHO, that's what hurt them so badly in the 90s after Ken Olsen left. They wanted to LMF license every little bit of Tru64 and VMS. There is the hobbyist program, yes. However, you don't need to mess with that to download Linux, and that's still an accessibility gap. In order to prevent your goose that laid the golden egg from losing her value (as a dead or emulated goose), you need to kill the goose hunters. :-) Color me weirdo and rounding error since I mainly use NetBSD. It doesn't change the truth of your statement, though. :-) IMHO, C is the most portable language in the world, not Java. IIRC, many java runtimes are still written in C. Anytime someone makes a new processor one of the first things they do is port a C compiler, making a lot more stuff possible. I started learning and using Perl until all this weirdness happened and they bolted on OO etc... I'm not anti OO but it was all just too much more me. I bolted to Ruby and Lua. No disrespect to the Perl Monks, I just couldn't hang anymore. I mostly agree, but I would like to say a few things about security issues and C. * Buffer overflows and string format exploits are the biggest side-effects, security wise. They aren't nearly as common as they were. There is greater awareness among programmers, compilers, and scanning tools now (valgrind, rats, etc). Plus the exploit writers have found more fertile ground in things like SQL injection and CGI interfaces. * They are pretty easy to prevent most of the time, especially if you care enough to check or use something like stack-smashing prevention in your compiler. Also thinks like OS heap randomization has made exploits much harder. * Yes, they still happen, and still *can* happen, so I don't dispute that. I think this is some phrase I often throw around a little too cavalier. Just because a language isn't popular doesn't mean I can't learn something It boggles me, actually. There were some awesome Delphi coders out there. I thought they'd never be derailed, because they were actually *very* effective coders I'd seen really powering certain businesses. Did Borland hork things up or what ? And amazing things like Amoeba, Sprite, MOSIX and others have also sort of dried up and died on the vine. There were some great ideas there. I also get that things are lost in this type of "war" the merits and interesting side of LISP machines etc.. It's not a good thing. Hmm, was that before or after things like Desqview came along? I'd probably guess that's why or just the momentum DOS had for a while. Which was hard to believe for me, too. It must have been a cost thing. Folks could have had an Amiga, ST, Acorn, Mac, OS/2 (depending on how far back), a low-end Unix box, etc.. However, I guess ultimately people wanted whatever they could go to their local software shop and get software for. It still is a mystery to me why DOS was so popular. I know, man, there is no accounting for taste. Now, as you also allude to, they have started to copy Windows. Linus seems to have shifted his attitudes greatly. Check out what he says about GGI then what he says about Systemd: From: http://marc.info/?l=linux-kernel&m=89089527200744&w=2 "I don't see the world in black-and-white. I don't actually like Linux-only features unless they have a good reason for them, and I really like Linux to be a "standard" system " -Linus 1998 " I'm distrustful of projects that do not have well-defined goals, and well-defined interfaces. They tend to bloat and do "everything" over time. This is what gives us horrors like GNU emacs and Mach: they don't try to do one thing well, they try to do _everything_ based on some loose principle [..]" -Linus 1998 Now fast forward to 2015: "I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area." -Linus 2015 I'll leave the readers to decide if that's hyperbole or there is something real there. It'll probably split right down the fracture point with systemd haters vs advocates, I suppose. It still seems pretty emblematic to me. My theory is that once folks woke up to the potential the Internet had for improving their real lives, they didn't care how much they polluted the computing world to get access to that power, and they weren't about to abide having to learn anything new if they didn't have to. My personal opinion is that though those devices might give devs a taste of *some* of the power of Unix, none of those devices show the *user* any of the so-called "Unix philosophy" (KISS, everything is a file, etc..). What's also sad is that those users don't give a hoot. However, I'm not really surprised. I grew up in an era when computers were NOT cool for kids. If you liked them or wanted to play games on a computer, that made you a "nerd" or "geek" when those words were purely pejorative. Now those same people can't look up from their phones long enough to keep from falling down stairs, walking in front of subway trains, or uhh.... living. I still carry a Symbian phone since I find both Android and iOS so invasive and annoying. It's a strange shake up on the world I grew up in. Plan 9 is still being (very slowly) developed. Ken is still involved last I heard. Right there with you, Liam. Someone posted today about the good parts of the Internet that we got with the deal. Massive communication and documentation are truly positive side effects for the most part. However, I suppose I have mixed feelings, nonetheless. Yes, and even though there is *more* overall documentation on the Internet, the docs you get with hardware and tools are nowhere near as good as they were in the 80s AFAIK. Nobody ships manuals with source code and schematics. The last I saw of that was BeOS and The Be Book. Well, when it comes to that front, I've been in this business for about 20 years now, and I don't understand those efforts. I see that and I can better appreciate where you are coming from when you couch it this way. Only the good die young. "Some will rise by sin and some by virtue fall." -Shakespear I completely understand. I am sorry for associating LISP with some crappy experiences I had in school 20 years ago. You and other folks come from a noble tradition. It was wrong of me to scorn that, even for an unrelated reason. -Swift

From: Liam Proven Sent: Thursday, April 28, 2016 6:39 AM BTW, an expansion for someone who missed a humorous point very early on: "FTHI" means "For the humour-impaired", and was followed by numerous smilicons. I received undergraduate and graduate degrees in historical linguistics; all my computer science background is due to my own self-directed study--and I do mean study. I've read any number of primary papers and books in the field, since that study made me better at using computers for what I really wanted to do. I've implemented compilers, and even my own Lisp interpreter, just for the fun of it. I am not one of the Lisp gods. The closest I came was interviewing for a systems programming job at the MIT AI Lab (dinner with Pat Winston at O'Hare one late fall evening when he had a layover). I went to work at Stanford the next year. I studied Lisp from the ground up: Read the Weisman LISP 1.5 book, read the LISP 1.5 Primer by McCarthy et al., read the sources to Portable Standard Lisp and MDL (and the MDL books from MIT), read Abelson&Sussman and the Common Lisp book (1st ed.). At the same time, I read many papers in artificial intelligence of the 1970s and early 1980s, most interested in natural language processing and knowledge representation. I've never done anything for money with either my degrees or my AI studies. I've supported myself and my wife as a systems programmer on IBM and DEC big iron, the latter eventually leading directly to working at the museum. As you might imagine, I'm a good bit older than either of you; I started at university (since you both want to equate "college" with "trade school"; in the US, we usually say "go to college" even if the institution grants higher degrees as well) before Liam was born. I was married and in grad school by the time Swift came along. I'm sorry that Swift took amiss my intended humor, but it's sparked an interesting long thread. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

On Thu, 28 Apr 2016, Rich Alderson wrote: That is an interesting field of study. I don't really understand a lick of it (talk about jargon! nobody beats linguists) but it's neat. As academic fields go, I'd do operations research if I ever went back. Those guys seem to be the brusin' bad dudes of math when it comes to getting things done. I've read some Dijkstra, Knuth, Jacob Ziv, and some stuff by David Wheeler, Martin Hellman, and a few others. The math for the last three is pretty well over my head but I got about 80%. What I read is mostly for implementation and "applied" reasons, but it's still interesting. Making compilers is fun. I've done it a couple of times using Jack Crenshaw's old papers (and he quotes Chomsky!). The lexical scanning tools are a lot better, now though. It's actually not too bad of an exercise if you don't have to extend or maintain the language afterwards. :-) It just seems like using the world "college" irritated fewer people when I implied that training & education were not mutually exclusive. It feels like some folks really recoil at that idea for universities. I just wonder how they apply that same principle to law school, nursing, metallurgy, etc... All (at least) 4 year degrees from universities where you'd darn well better come out with some training, or you are going to be in something of a pickle (failing the bar, losing your license, burning your face off, etc..). Maybe it's only for CS, since that's all we've mostly been talking about, and that's fair. I was born in 75, graduated (high school) in 1993, and dropped out of college in 1998. Ah, did I? Sorry about that. I'm always game for a good joke. -Swift

The regular expression support in Perl is implemented in C, and are supposedly fairly fast. That didn't stop a Lisp programmer from implementing PCREs in Lisp (that supposedly slow and inefficient language), and getting better performance than Perl :-)

It's not *generally* the case that cl-ppcre is faster than PCRE - it depends completely on the (Common) Lisp implementation that it is running in. The original benchmark was run using CMUCL, which is generally considered to be a high-quality, fast implementation of Common Lisp. The benchmarks are not part of the cl-ppcre homepage anymore, but an old version can be found at the Wayback Machine <http://web.archive.org/web/20080624164217/http://weitz.de/cl-ppcre/#bench>.

??? Base FORTH is not, in and of itself, threaded. PolyFORTH was if memory serves. Then again, creating a thread scheduler (cooperative scheduler) for FORTH is just a modest exercise for the programmer. paul

On Fri, Apr 29, 2016 at 09:13:42PM +0200, Raymond Wiker wrote: Sure. Adobe postscript is a thread interpretative language (TIL). It looks very much like FORTH if you squint real hard. Also, old DEC Fortran looks very TILish if you didn't use the option to generate native PDP-11 code. ;) My own 6502 emulator written in 68K asm looks very TILish as well. ;) -- - db at FreeBSD.org db at db.net http://www.db.net/~db

You'd have to squint pretty hard. I'd say that PostScript is FORTH with the stacks hidden and more datatypes added. The major thing it shares with FORTH is that it's a postfix stack language. It does not have things like R> and >R, or immediate words, or any of many other things that FORTH can support _because_ it's threaded code running in an interpreter with very simple data structures for things like dictionaries. I find it easy to credit, actually; the only part of PS that I see as layable at FORTH's doorstep is the use of a postfix stack model for primitives' inputs and outputs. PS has a lot of other things FORTHs (in my admittedly limted experience) don't, such as many compound types as first-class objects (dictionaries and arrays are the big ones), data-as-code at a level that, while not quite up to Lisp, is far more abstract that FORTH's "assemble a vector of threaded-code pointers" model, and a number of hidden data types (hidden in that they are not first-class language objects) like paths and graphics states. Also, PostScript has a lot of language syntax, whereas FORTH has immediate words that act like language syntax. (The difference is that FORTH makes it possible to change those words, thereby changing the apparent syntax.) As for run-time versus compile-time name binding, PostScript does not normally have any "compile time", since it's not normally compiled. The closest thing is the assembling of an executable array, which you can convert to "compile-time" binding with the bind primitive (as in "/foo { dup cos exch sin } bind def", versus the same thing without the bind). A PS engine may use threaded code, but it does not need to; the language is insulated enough from the implementation that it is difficult-to-impossible for the PS programmer to tell. FORTH is much less insulated. I am offering no value judgement either way. In some respects, the above differences make PostScript the better language; in others, FORTH. And that's as I think it should be: different languages for different purposes. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Consider a simple definition : foo swap - ; ( inverted subtraction ) /foo { exch sub } def % inverted subtraction (The first is FORTH[%], the second PostScript.) Each of these has some "syntax" bits. In FORTH, :, ;, (, and ). In PostScript, the leading /, {, }, and %. The difference is that in FORTH, you can create new immediate words and/or redefine the existing ones; : can do something other than beginning the definition of a word, and you can arrange to begin the definition of a word with something other than :. In PostScript, none of this is mutable short of hacking on the underlying implementation (and if you do that the result isn't PostScript any longer). [%] I think. I don't really know FORTH; does it use - for subtraction? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sun, May 22, 2016, Mouse wrote: Interesting. I thought { } were just plain old words, but I'll at least concede the rest. -- Eric Christopherson

Ben, All Forth implementations are threaded, but there are several kinds: direct, indirect, token and subroutine. Initially indirect threading was the most popular implementation choice but all Forth chips I am familiar with use subroutine threading instead. Subroutine threading has the highest performance, but it does take up more space (each word uses a CALL opcode as well as the word's address) and it kills CREATE DOES>, which is what you were asking about. There are two solutions to this problem: in Color Forth you can type a word in either green or yellow depending on whether you want its action to happen at runtime or at compile time while in Machine Forth you can define a word in either the normal vocabulary or the macro vocabulary to get a similar effect. The advantage of compile time words (which are different from playing with the COMPILE flag in threaded Forths) is that you can inline the code that would normally be in the DOES> portion of the word, which saves you a call and a return. For a normal processor that might take up more space, but for Forth chips this will almost always be a single instruction which is much smaller than a call so you actually save memory instead. -- Jecel https://en.wikipedia.org/wiki/Threaded_code#Threading_models

True, but... ...this is also true, and it means the development of a mindset that's better equipped to catch higher-level mistakes as well as the low-level mistakes. It's true that C is easy to use unsafely. However, (a) it arose as an OS implementation language, for which some level of unsafeness is necessary, and (b) to paraphrase a famous remark about Unix, I suspect it is not possible to eliminate the ability to do stupid things in C without also eliminating the ability to do some clever things in C. Of course, the question is not whether C has flaws. The question is why it's still being used despite those flaws. The answer, I suspect, is what someone said about it being good enough. I would have no problem with them if they were documented. But I've yet to find one that is. I worked on a project writing code for a new Android phone, once, and even as developers we had to use binary blob drivers for important pieces. (It also taught me how horrible the Android build system is.) Mind you, if/when I find one that _is_ documented.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 04/29/2016 10:49 AM, Mouse wrote: My gripe with C is essentially the same as my grumbles with APL--it's far too easy to write obscure code and not document it. Old versions of UNIX are full of that sort of thing. Being a low-level language, it's almost as bad as lines and lines of assembly without a single comment. Why it appeals to this particular foible of human nature has always been a mystery to me. On the embedded systems (read MCU) front, I note that Ada is starting to gain some real traction, which I applaud wholeheartedly. --Chuck

On Fri, Apr 29, 2016 at 11:22 AM, Mouse <mouse at rodents-montreal.org> wrote: It's not a bad or defective tool - in fact, it's a very useful and powerful tool. But IMHO she lacks the 'situational awareness' to safely deal with an unprotected blade going back and forth several thousand times a minute. C is a lot like that saw - it doesn't have a lot of guards on it, and you can do stupid things. But you can do very powerful things that are difficult or impossible in, say, Python, which is also a very good and useful tool. Don't blame the tools - blame an educational system that doesn't teach software engineering practice, but just teaches tools. "Hey, hold my beer and watch this!" -- Ian -- Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <http://ischool.uw.edu> Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical Narrative Through a Design Lens Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org> Value Sensitive Design Research Lab <http://vsdesign.org> University of Washington There is an old Vulcan saying: "Only Nixon could go to China."

On 4/29/16 12:43 PM, Chuck Guzis wrote: Find libraries that other people have written, glue something together, and move on to the next project/job. Then scream if you try to rebuild it later and the new version of the libraries didn't maintain backwards compatibility and the guy who glued it togther is gone.

On 29 April 2016 at 15:43, Chuck Guzis <cclist at sydex.com> wrote: The answer, apparently: Step 1: Install package manager of choice. Step 2: Create a blank project using the package manager and Framework X (which is the "in" thing this week). Step 3: Slap together two lines of code which are: theThing.do(); theThing.show(); Step 4: Pray to every deity in existence no one changes anything in the TWENTY-EIGHT THOUSAND dependencies of your blank file. Step 4b: Shoot yourself in the head when someone "unpublishes" their shitty eleven line implementation of the left pad function/algorithm which promptly breaks your everything. No you didn't use it, but it's somewhere inside your 28000 (yes, really, twenty-eight thousand, that's not a typo) dependencies needed to work your blank jspm/npm-based app template. Step 5: Shoot yourself in the head again because "Dude! Like, Framework X is soooo uncool right now. Everyone's using Framework Y!" or Framework X completely changes everything in the way it functions. Because Reasons?. Seriously, here's a blog post about the relatively recent fact that one person managed to break some of the "big name" JavaScript frameworks/apps/whatever-the-shit-they're-called-now: <http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/> "Functions are not packages," the author states, and I agree fully. This is considered a "package" in the JavaScript world of the npm package manager: return toString.call(arr) == '[object Array]'; Yes, one line. The "isArray" package, on which seventy-two (72) other packages depend. Best thing is there's people in the comments defending this kind of insanity as "hiding complexity." If you can't write something as simple as a left padding function yourself because it's too complex, why in the name of all things holy should I let you even go near any kind of software development? </rant> Regards, Christian -- Christian M. Gauger-Cosgrove STCKON08DS0 Contact information available upon request.

On Fri, Apr 29, 2016 at 02:23:55PM -0600, Eric Smith wrote: Yes it is known as a high level assembler. -- - db at FreeBSD.org db at db.net http://www.db.net/~db

I would actually argue that C++, Java and C# are not object-oriented languages. They are languages with syntax that supports object-oriented programming - note that the original C++ was a preprocessor for a C compiler. Smalltalk, Simula, and more recently languages like Ruby are object-oriented languages. You can write object-oriented code in any language, if you construct your code to express the abstractions of OO. It's easier, of course, in a language that has syntactic sugar like 'classes' or 'interfaces'. And IMHO C was designed for writing operating systems and tools, and that's where it shines. It's still highly relevant for embedded systems, for instance. Again IMHO, the quality of C compilers is such that the relative benefits/costs of C vs. assembler usually lean toward using C, because it does support higher-level abstractions (especially helpful on RISC architectures) and it can be written to be more transparent - bringing us back to the original point of how you use the tools. -- Ian On Fri, Apr 29, 2016 at 1:37 PM, Raymond Wiker <rwiker at gmail.com> wrote: -- Ian S. King, MSIS, MSCS, Ph.D. Candidate The Information School <http://ischool.uw.edu> Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical Narrative Through a Design Lens Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org> Value Sensitive Design Research Lab <http://vsdesign.org> University of Washington There is an old Vulcan saying: "Only Nixon could go to China."

On 4/29/2016 2:23 PM, Eric Smith wrote: I like C for the most part, what you see is what you get. With other stuff, it is too abstract. What does it do? Ben. For humor see this link, but only if you have shoes on. http://www.thealmightyguru.com/Humor/Docs/ShootYourselfInTheFoot.html

On Fri, Apr 29, 2016 at 01:36:29PM -0700, Al Kossow wrote: bit fields is another part of C that should be removed ;) It seemed like a good idea when we started ;) -- - db at FreeBSD.org db at db.net http://www.db.net/~db

On Fri, Apr 29, 2016 at 03:55:35PM -0700, Chuck Guzis wrote: Now wait a minute here. C is a very old language. When it was first written as a recursive descent compiler, compiler technology was very primitive. K&R style code with primitive compilers pretty much resulted in high level assembler. Look at the keyword 'register' and the rationale given for it. Now on that we furiously agree. One problem has been getting that through to people who insist that C is still a high level assembler and has not changed from the time when it was a hand crafted recursive descent LR to the modern compiler with all the lovely optimisations we can do. The best way of viewing it is to acknowledge that modern C is effectively a new language compared to old K&R C that had no prototypes. ditto. Diane -- - db at FreeBSD.org db at db.net http://www.db.net/~db

On Sat, Apr 30, 2016 at 7:39 AM, Diane Bruce <db at db.net> wrote: Sure, the compilers are way better than they were back then. That doesn't make the language itself any higher level. The semantic level of the language and the level of abstraction it provides have barely changed, so the language itself is still a mostly portable substitute for assembly language. As Chuck points out, it isn't a good substitute for any particular CISC assembly language, but then those aren't portable at all.

On Apr 30, 2016, at 11:43 AM, Diane Bruce <db at db.net> wrote: In support of this, I?d encourage everyone who works with C to read Chris Lattner?s ?What Every C Programmer Should Know About Undefined Behavior? series from the LLVM blog: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html C has fairly well-defined semantics, they just aren?t necessarily what you think they are, and optimizers are taking advantage of them (under the ?as if? rule) such that a developer?s idea of what assembly a specific section of C code should generate is not all that accurate these days. -- Chris

Reading this really gives me the impression that it's time to fork C. There seems to me to be a need for two different languages, which I might slightly inaccurately call the one C used to be and the one it has become (and is becoming). The first is the "high-level assembly" language, the one that's suitable for things like embedded programming in what C99 calls a standalone environment, kernel and low-level library implementations, and the like, where you want to do whatever's reasonable from the point of view of someone who knows the target machine architecture, even if it's formally undefined by the language. The second is more the language the author of those posts is talking about, where the compiler is allowed to do surprising things for the sake of performance. The zero_array example slightly bothers me, because the optimization into a memset is valid only when floating-point zero is all-bits-zero; while this is something the compiler can know, and is true on "all" machines, the way it's written doesn't call it out as a machine-dependent optimization, quite possibly leading people to write the memset themselves in such cases, producing a different bug. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

It was thus said that the Great Chuck Guzis once stated: I believe that's what the C99 keyword "restrict" is meant to address. -spc

On 2016-04-30 5:20 PM, Chuck Guzis wrote: Indeed. John Regehr writes more on this in this recent post: http://blog.regehr.org/archives/1307 --Toby

On Sat, Apr 30, 2016 at 05:07:08PM -0400, Mouse wrote: It has been effectively forked for a long time. Same name. Look at Fortran II vs. more modern Fortran. The pain of counting characters for the H command... ugh. Diane -- - db at FreeBSD.org db at db.net http://www.db.net/~db

What does a recursive decent parser to do with code generation and optimization? All of the compilers I wrote (admittedly it?s been decades since I wrote one ?program tree? that the global optimizer walked to do transforms that were the ?global? optimizations. The code generator took the output, generated code for a synthetic machine. That was then gone over by the target code generator to do register allocation and code generation to the final ISA. The result of this flow generated pretty respectably optimized code. The parser was *very* removed from the code generation. Frankly, I fail to see what the implementation choice for the parser has on the quality (or lack thereof) of the generated code. ANSI C is the ?modern C? vs K&R C. However, even ANSI C evolves every few years to what is effectively a new variant of C that maintains some backwards compatibility with older versions. TTFN - Guy

On Fri, 29 Apr 2016, Eric Smith wrote: I like the title that Holub chose for his book: "Enough Rope To Shoot Yourself In The Foot"

On Fri, Apr 29, 2016 at 01:49:11PM -0400, Mouse wrote: Sooooooo true. I forget on here sometimes. ;) My objection is to the effort to fix what should not be fixed in 'C' and not fixing what should be fixed in a OS implementation or library/utility language. C's success is breeding a lot of bad code(rs). It's too damn portable a language. I'd also like to see more emphasis on something other than C. We furiously agree here. Diane -- - db at FreeBSD.org db at db.net http://www.db.net/~db

It was thus said that the Great Liam Proven once stated: By the late 80s, C was available on many different systems and was not yet standardized. The standards committee was convened in an attempt to make sense of all the various C implementations and bring some form of sanity to the market. All those "undefined" and "implementation" bits of C? Yeah, competing implementations. For instance, why is signed integer arithmetic so underspecified? So that it could run on everything from a signed-magnitude machine [1] to a pi-complement machine (with e-states per bit [2]). Also, to give C implementors a way to optimize code [3][6]. And because of the bizarre systems C can potentially run on, pointer arithmetic is ... odd as well [4]. It also doesn't help that bounds checking arrays is a manual process, but then again, it would be a manual process on most CPUs [5] anyway ... -spc (Wish the C standard committee had the balls to say "2's complement all the way, and a physical bit pattern of all 0s is a NULL pointer" ... ) [1] I think there was only one signed-magnitude CPU commercially available, ever! From the early 60s! Seriously doubt C was ever ported to that machine, but hey! It could be! [2] 2.71828 ... [3] Often to disasterous results. An agressive C optimizer can optimize the following right out: if (x + 1 < x ) { ... } Because "x+1" can *never* be less than "x" (signed overflow? What's that?) [4] Say, a C compiler an 8088. How big is a pointer? How big of an object can you point to? How much code is involved with "p++"? [5] Except for, say, the Intel 432. Automatic bounds checking on that one. [6] Trapping on signed overflow is still contentious today. While some systems can trap immediate on overflow (VAX, MIPS), the popular CPUs today can't. It's not to say they can't test for it, but that's the problem---they have to test after each possible operation. And not all instructions that manipulate values affects the overflow bit (it's not uncommon on the x86, for instance, to use an LEA instruction (which does not affect flags) to multiple a value by small constants (like 17 say) which is faster than a full multiple and probably uses fewer registers and prevents clogging the piplelines).

It was thus said that the Great Swift Griggs once stated: In 1988, C had yet to be standardized. In 1989, ANSI released the first C standard, commonly called ANSI C or C89. I stared C programming in 1990, so I started out with ANSI C pretty much compiler can catch more errors. The difference between the two? ANSI codified existing examples where as ISO created a standard in a vacuum and expected people to write implementaitons to the standard. A long long is at least 64-bits long. And Lua can run on as many OSs and CPUs as C. Just be thankful you never had to program C in the 80s and early 90s: http://www.digitalmars.com/ctg/ctgMemoryModel.html Oh, wait a second ... http://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models What's wrong with the following code? p = malloc(sizeof(somestruct) * count_of_items); Spot the bug yet? Here's the answer: it can overflow. But that's okay, because sizeof() returns an unsiged quantity, and count_of_items *should* be an unsigned quantity (both size_t) and overflow on unsigned quantities *is* defined to wrap (it's signed quantities that are undefined). But that's *still* a problem because if "sizeof(somestruvt) * count_of_items" exceeds the size of a size_t, then the result is *smaller* than expected and you get a valid pointer back, but to smaller pool of memory that expected. This may not be an issue on 64-bit systems (yet), but it can be on a 32-bit system. Correct system code (in C99) would be: if (count_of_items > (SIZE_MAX / sizeof(somestruct))) error(); p = malloc(sizeof(somestruct) * count_of_items); Oooh ... that reminds me ... I have some code to check ... Don't discount GC though---it simplifies a lot of code I'm generally not a fan of shared libraries as: 1) Unless you are linking against a library like libc or libc++, a lot of memory will be wasted because the *entire* library is loaded up, unlike linking to a static library where only those functions actually used are linked into the final executable 2) because of 1, you have a huge surface area exposed that can be exploited. If function foo() is buggy but your program doesn't call foo(), in a static compile, foo() is not even in memory; with a dynamically loaded library, foo() is in memory, waiting to be called [1]. 3) It's slower. Two reasons for this: 3a) It's linking at runtime instead of compile time. Yes, there are mechanisms to mitigate this, like lazy runtime linking (where a routine isn't resolved until it's called for the first time) but that only helps over the long term---it *still* has to be resolved at some point. 3b) Not all CPUs have PC (program counter) relative modes (like the relatively obscure and little used x86---ha ha) and because of this, extra codes needs to be included to do the indirection. So, your call to printf() is not: call printf but more like: call printf at plt printf at plt: jmp shared_lib_printf where printf at plt is constructed at runtime, *for every call in a shared library*. This indirection adds up. Worse, global data in a shared library becomes a multi-pointer-dereference mess. To see how silly this can be on a modern Linux system, run % ldd pick-your-executable for each process running and see just how many of those "shared" libraries are actually shared (in addition to the potential attack surface). Um, see the above malloc() example---it's not fixed there. I use the uintXX_t types for interoperability---known file formats and network protocols, and the plain (or known types like size_t) otherwise. It was a joke. Have you actually looked into the Intel 432? Granted, there's not much about it on the Internet, but it was slow. And it was slow even if you programmed in assembly! You miss the point. I mean, an expression like: y = 17 * x + 5 can't be optimized: mov edx,eax shl eax,4 lea ecx,[eax+edx+5] but has to be: imul eax,17 jo error ; [2] add eax,5 jo error For some perspective on this, there are two blogs I would recommend. The first is "programming in the twenty-first century": http://prog21.dadgum.com/ and the second on compiling and optimizing C code: http://blog.regehr.org/ -spc (Sigh---called into work to debug a production problem with C and Lua) [1] How can a program that doesn't call foo() be enticed with calling foo()? Return-oriented programming. https://en.wikipedia.org/wiki/Return-oriented_programming [2] Using INTO is slow: http://boston.conman.org/2015/09/05.2 while JO isn't: http://boston.conman.org/2015/09/07.1 mainly because JO can be branch-predicted and so the overhead of the actual JO instruction is practically zero. On the other hand, the fact that you have to use JO means more code, which could increase presure on the I-cache, *and* you have to use instructions which set the O flag (LEA does not). It's this (having to use instructions to set the O flag) that cause perhaps as much as a 5% penalty (worse case), depending upon the code.

It was thus said that the Great Mouse once stated: I keep telling myself that whenever I launch Firefox after a reboot ... First off, the C standard mandates that the order of fields in a struct cannot be reordered, so that just leaves padding and byte order to deal with. Now, it may sound cavalier of me, but of the three compilers I use at work (gcc, clang, Solaris Sun Works thingy) I know how to get them to layout the structs exactly as I need them (and it doesn't hurt that for the files and protocols we deal with are generally properly aligned anyway for those systems that can't deal with misaligned reads (generally everything *BUT* the x86)) and that we keep everything in network byte order. [1] -spc [1] Sorry Rob Pike [2], but compilers aren't quite smart enough [3] yet. [2] https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html [3] https://news.ycombinator.com/item?id=3796432

Given that C is a systems implementation language, how would you define HW related data structures where the order of the fields is critical (ie HW defines them). That?s why there are #pragmas and other compiler directives (i.e. ?packed?) to handle this. My biggest complaint about the C standard is that the order that bits within a bit field are compiler defined. This basically means that they are completely unusable for anything that requires interoperability. TTFN - Guy

I can see three answers. 1) Don't use structs for that. Look at NetBSD's bus-space abstraction for one possible way. 2) Make any reordering implementation-defined, so that code for specific implementations can know how the implementation does it. 3) Make reordering optional. Which way the default should go is arguable; since my guess is that most structs are not hardware-interface structs, the default should be reordering, with some keyword specifying no reordering. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sun, 22 May 2016, Mouse wrote: 4) While the C language standard may not mandate it itself, a specific system ABI may require a particular bitfield, structure, etc. layout which C compiler implementations for that platform need to adhere to, and then you can rely on that. Of course that does not solve the problem for code which has to be portable across systems (e.g. option card drivers), but there you usually need to take extra care for differences between systems (e.g. endianness) anyway. Maciej

Oh, foo--in 40 years, "C" will be just a quaint recollection in the minds of the old-timers. Like JOVIAL. --Chuck

On 2016-05-21 10:26 PM, ben wrote: Don't underestimate the headache of handling two zeroes. --Toby

On 5/21/2016 8:56 PM, Jon Elson wrote: I favor TWO zeros over 2's compliment 0x80... 0 number that is always a minus. 0 and 1 for logic word size only. The big thing is to know your hardware, one machine does not fit all. Ben.

On 05/21/2016 07:34 PM, Toby Thain wrote: At least on the CDC iron, it was never much of a problem. The primary way you got -0 as a result (without resorting to boolean operations), was subtracting -0 from -0. The ZR/NZ operations worked on either sign. Note that, on the fullword 60-bit operations, the conditionals were based on the contents of a single register. To compare, you had to subtract or otherwise operate on two operands and branch on the content of the result. There were no condition codes--something that made instruction scheduling much simpler. The 18-bit index register conditionals (EQ, NE, GT...etc.) didn't usually see -0 as a problem. Ones complement did have advantages in bit twiddling--there were some nifty tricks not possible in two's complement. Of course the CDC 6000 series was word-addressable--something that seemed eminently practical. As far as I'm aware, the possibility of two zeroes never impacted the performance of the CDC 6000 series in the real world. --Chuck

On 05/22/2016 06:23 AM, Toby Thain wrote: Well, if you consider it carefully, does zero really have a sign? So, the convention of considering 0 to be a positive value is, in a sense, illogical. But no, I don't recall that the issue of -0 ever raised much of a problem in either CP or PP code. I've long wondered if the abandonment of ones' complement arithmetic on modern ISAs was more due to the requirement that ones; comp requires an end-around carry, where two's comp does not. --Chuck

As far as I'm concerned, this is different only in degree from `Wish the C standard committee had the balls to say "Everything is x86".'. More precisely, because signed overflow invokes undefined behaviour, meaning that, for values of x where x+1 overflows, the program can behave in any way whatever and still be within spec. Including, say, skipping the stuff inside the { } block. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

There are probably a couple hundred Unisys 2200 systems left in the world (no one really knows the true number). Of course, when the C standards were being drawn up, there were many more, with a small but significant share of the mainframe market. -- Will (C sucks)

Sean Conner <spc at conman.org> writes: Aka UNISYS 1100/2200, aka ClearPath ix, aka ClearPath OS 2200. https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series

On Sat, 21 May 2016, Liam Proven wrote: Thanks for posting that. I read the Reg but not on "the reg" so that one missed me. Downloading now! Sounds like fun ;) Best, Sean

On 5/21/2016 6:42 AM, Liam Proven wrote: Strange how 36 bit computers have never left us. The real computers go to the US Goverment, and Windows goes to the UNWASHED MASSES. I wonder how things would have changed if the PDP 11 was 18 bits? Ben.

On 21 May 2016 at 17:33, William Donzelli <wdonzelli at gmail.com> wrote: Yes it is, but they are x86 boxes running an emulator. http://www.theregister.co.uk/2015/05/26/unisys_finally_weans_itself_off_cmo… AFAIK only IBM is still making actual hardware mainframe processors. The handful of other remaining vendors are all using software emulation on generic x86 hardware. High-end hardware, sure, yes. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 21 May 2016 at 17:58, William Donzelli <wdonzelli at gmail.com> wrote: I thought it was noteworthy considering that this subthread originated in discussion of how all contemporary processors conformed to certain norms. This example of one that doesn't -- a 36-bit processor which doesn't use 2's complement and so on -- today exists only as a software emulation on an underlying architecture that /does/ conform and which thus doesn't really resemble the architecture being emulated. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

It was thus said that the Great Mouse once stated: I'd wager that most C code is written *assuming* 2's complement and 0 NULL pointers (and byte addressable, but I didn't ask for that 8-). That the C Standard is trying to cover sign-magnitude, 1's complement and 2's complement leads to the darker, scarier, dangerous corners of C programming. I've been reading some interesting things on this. "Note that removing non-2's-complement from the standard would completely ruin my stock response to all "what do you think of this bit-twiddling extravaganza?" questions, which is to quickly confirm that they don't work for 1s' complement negative numbers. As such I'm either firmly against it or firmly in favour, but I'm not sure which." ... "[W]rite a VM with minimal bytecode and that uses 1s' complement and/or sign-magnitude. Implement a GCC or LLVM backend for it if either of them has nominal support for that, or a complete C implementation if not. That both answers the question ("yes, I do now know of a non-2's-complement implementation") and gives an opportunity to file considered defect reports if the standard does have oversights. If any of the defects is critical then it's ammunition to mandate 2's complement in the next standard." http://stackoverflow.com/questions/12276957/are-there-any-non-twos-compleme… Personally, I would *love* to see such a compiler (and would actually use it, just to see how biased existing code is). From reading this comp.lang.c++.moderated thread: https://groups.google.com/forum/?hl=en&hl=en#!topic/comp.lang.c++.moder… I'm not even sure size_t foo = (size_t)-1; is legal, or even does what I expect it to do (namely---set foo to the largest size_t value possible (pre C99). Now, I realize this is the Classic Computers Mailing list, which include support for all those wnoderful odd-ball architectures of the past, but really, in my research, I've found three sign-mangnitude based computers: IBM 7090 Burroughs series A PB 250 (the IBM 1620 was signed-magnitude, but decimal based, which the C standard doesn't support. And from what I understand, most sign-magnitude based machines were decimal in nature, not binary, so they need tno apply) and a slightly longer list of 1's complement machines: Unisys 1100/2200 PDP-1 LINC-8 PDP-12 (2's complement, but also included LINC-8 opcodes!) CDC 160A CDC 6000 Electrological EL-X1 and EL-X8 I won't bother with listing 2's complement architectures because the list would be too long and not at all inclusive of all systems (but please, feel free to add to the list of binary sign-magnitude and 1's complement systems). Of the 1's complement listed, only the Unisys is still in active use with a non-trivial number of systems but not primarily emulated. To me, I see 2's complement as having "won the war" so to speak. It is far from "idiosyncratic." And any exotic architecture of tomorrow won't be covered in the C standard becuase the C standard only covers three integer math implementations: signed magnitude 1's complement 2's complement If tinary or qubit computers become popular enough to support C, the C standard would have to be changed anyway. The initial C standard, C89, was a codification of *existing* practice, and I'm sure IBM pressed to have the C standard support non-2's complement so they could check off the "Standard C box." Yes, Unisys has a C compiler for the Unisys 2200 system and one that is fairly recent (2013). But I could not find out if it supported C99, much less C89. I couldn't tell. And yes, you can get a C compiler for a 6502. They exist. But the ones I've seen aren't ANSI C (personally, I think one would be hard pressed to *get* an ANSI C compiler for a 6502; it's a poor match) and thus, again, aren't affected by what I'd like. I'm not even alone in this. Again, for your reading pleasure: Proposal for a Friendly Dialect of C http://blog.regehr.org/archives/1180 The Problem with Friendly C http://blog.regehr.org/archives/1287 Both are written by a professor working on tools to make using C safer. Twenty years ago, the "all the world's on x86" (1996). *Thirty* years ago, and yes, I would agree 8-P -spc

While I think that size_t foo = (size_t)(-1); is what C would interpret as being meant. What the size of the thing that by default, in this implementation, -1 would be stored in. On 22 May 2016 at 14:09, Mouse <mouse at rodents-montreal.org> wrote: -- 4.4 > 5.4

Only if size_t is no larger than unsigned long int (unsigned long long int for the ULL version). I don't think that's guaranteed. Mouse

unsigned long long int isn't necessarily the largest integral type. Nor do I see anything requiring size_t to be no larger than it. uintmax_t, on the other hand, would be fine; it _is_ promised to be no smaller than size_t (or any other unsigned integral type). size_t foo = ~(uintmax_t)0; should work fine to set foo to all-bits-set. (Since size_t is unsigned, this will set it to be its largest possible value.) I think uintmax_t is another blemish in the standard, since it makes certain kinds of innovation impossible. (For example, the presence of uintmax_t makes it impossible to extend the compiler to recognize uintXX_t as "unsigned integer type with at least XX bits" for all XX, presumably with library support for integers over hardware-supported sizes. At least without no longer, strictly, being a C compiler.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On May 22, 2016, at 6:09 AM, Mouse <mouse at Rodents-Montreal.ORG> wrote: Just use Symbolics C on a Symbolics or ZetaC on a TI Explorer. (ZetaC was recently put in the Public Domain by its author, so you can take a look at how it was implemented.) Both of them I believe implemented C89. There?s also someone writing a C to Common Lisp translator that takes some of the same approaches as those compilers: <https://github.com/vsedach/Vacietis> Something like that would make it possible to pull C code into a project like Mezzano. (Another approach would be to write an LLVM back-end that generates Common Lisp using the same approach as ZetaC, and port clang to it.) -- Chris

On 5/20/2016 2:58 How come INTEL thought that 64 KB segments ample? I guess they only used FLOATING point in the large time shared machines. Ben.

Because the 808x was a 16-bit processor with 1MB physical addressing. I would argue that for the time 808x was brilliant in that most other 16-bit micros only allowed for 64KB physical. If people wanted more they had to add external hardware and the calling linkage became problematic (I know because that?s what we did on the IBM S/23 Datamaster that used an 8085 and allowed for 192KB of ROM and 128KB of RAM). Floating point was not common at the time in micros because of the number of transistors/gates necessary for the implementation. Intel added it as a ?coprocessor? in the 8087. When I was at IBM we continually railed on Intel to make floating point standard so that we could have code that assumed floating point was always present. It finally happened with the 80486 but then Intel took it away again (sort-of) with the 486-SX which was brilliant marketing by Intel?initially allowed them to sell ?floor swept? 486?s with non-functional floating point units?eventually their process improved and more often than not 486-SX systems that had the floating point coprocessor actually had 2 fully functional 486 processors! TTFN - Guy

Without an MMU or a segmentation scheme, 16-bits = 64K. The 68000 is not a 16-bit processor, it's 32-bit, and exposed (ISTR) a 24-bit address. 20-bits = 1M addresses, 24-bits = 16M addresses. You're confusing data bus width (8-bit) with address bus width (16-bit). ----- Original Message ----- From: "Liam Proven" <lproven at gmail.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Tuesday, May 24, 2016 1:29:48 PM Subject: Re: strangest systems I've sent email from On 22 May 2016 at 04:52, Guy Sotomayor Jr <ggs at shiresoft.com> wrote: Er, hang on. I'm not sure if my knowledge isn't good enough or if that's a typo. AFAIK most *8* bits only supported 64 kB physical. Most *16* bits (e.g. 68000, 65816, 80286, 80386SX) supported 16MB physical RAM. Am I missing something here? I always considered the 8088/8086 as a sort of hybrid 8/16-bit processor. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On Tue, 24 May 2016, Fred Cisin wrote: This was always the biggest pustule on the facade of x86 to me. Gate A20 and other chicanery was nasty business. It always struck me as a hardware hack to work around earlier bad design. Sure, you can eschew segmentation and try to use multiple instructions to delivery some flat addressing, and then your code was snail-slow. Real mode in 16 bit on x86 was/is some fairly vulgar stuff due to segmentation (hate hate hate). Then it was made "all better now" by protected mode and segment descriptors later *pat pat*. Yeah. Ugh. Pleah. Ick. All that fun sent me running into the arms of the M68k and it's git, and later MIPS (queue hallelujah chrous from the clouds). I'm not a MIPS god (we have a some here), but much love and respect to the architecture nonetheless. I know enough to know "that's the good stuff". Nowadays I wonder, since I'm using flat memory on the Unix boxes I code in (now pretty much just in C, I haven't done ASM in a long while), what kind of masochist maintains the SLAB/SLUB allocators for x86 Unix variants these days. I want to buy them a six pack, pat them on the back, and say "you're a braver man than, I." -Swift

As someone who was there and participated in the whole A20 gate issue, I can tell you why it was there (and Intel in it?s most recent chipsets finally eliminated it). It was for SW compatibility. There was a well know piece of software (at the time?who?s name escapes me) that make use of the fact that on the 8088, addresses wrapped around at 1MB. They took great advantage of it. Unfortunately when IBM was working on the PC AT with a 80286 (with 24-bit physical addresses) the clever hack no longer worked. So we had to put in a way to emulate the wrap-around at 1MB?that was the A20 gate. The initial implementation of the A20 gate was implemented by the keyboard controller(!) because it was discovered late in the PC AT development cycle and we couldn?t add more logic to the board (but we could add some wires). TTFN - Guy

No it was to allow accessing memory without having to reload a segment register. It was a space and performance optimization. There was no additional memory. As I recall, SW needed to access something in the BIOS ROM(s) and also the contents of low memory. Normally, that would have involved reloading a segment register (and restoring it when done) but by organizing the code properly and setting the segment registers it was possible to access both the low *and* high regions without reloading a segment register. That is, put a large value in the segment register and when you wanted to access low memory, use a large offset. When you wanted to access high memory, use a small offset. You could access 32KB of high and 32KB of low without reloading a segment register (or any particular split you wanted). These are the sort of ?tricks? that most people don?t think much about when dealing with multi-GB memory environments. There are still cases where every byte (and cycle) count and doing these sorts of ?tricks? is what determines if the product is doable or not. TTFN - Guy

It was thus said that the Great Fred Cisin once stated: To further explain this. The 8086 (and 8088) was internally a 16-bit CPU. Since you could only address 64K, Intel used four "segment" registers to get around this limit. The four registers are CS, DS, ES and SS, and were the upper 16 bits of the 20-bit address [1]. A physical address was calculated as: +--------+--------+ | 16-bit segment |0000 +--------+--------+ +--------+--------+ + 0000| 16-bit offset | +--------+--------+ ========================= +----+--------+--------+ | 20-bit physical addr | +----+--------+--------+ Instructions were read from CS:IP (CS segment, IP register), most reads and write to data sent to DS:offset, with some exceptions. Pushes and pops to the stack went to SS:SP and reads/writes with the BP register also used the SS segment (SS:BP). The string instructions used DS:SI as the source address and ES:DI as the destination address. And you could override the default segment for a lot of instructions. So: mov ax,[bx] -- SRC address is DS:BX mov es:[bx],ax -- DEST address is ES:BX Technically, you could address as much as 256K without changing the segment registers. I got used to this, but I still preferred programming on the 6809 (8-bit CPU) and 68000. *Much* nicer architectures. -spc (And the 80386 introduced paging to this mess ... ) [1] Starting with the 80286, in proected mode, they are treated differently and no longer point to a physical address. But that's beyond the scope of *this* message.

On Fri, 27 May 2016, Liam Proven wrote: Of course. That is exactly the point. How you draw the line, determines which side it will fall, and it is right in the middle, so many otherwise reasonable definitions will differ on that group of chips, since it IS in between an 8 bit and 16 bit. Either an 8 bit that has been expanded to SOME 16 bit capabilities, or a 16 bit that has been cut down into an 8 bit.

On 27 May 2016 at 01:54, John Willis <chocolatejollis38 at gmail.com> wrote: Sorry! Typo. It's nearly 2AM here in Czechia. I think I need to go to sleep. :?( -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

Sean Conner <spc at conman.org> writes: Actually 23 address lines to select a 16-bit word in memory, plus UDS and LDS to select upper byte/lower byte/word.

On Apr 28, 2016, at 8:38 AM, Liam Proven <lproven at gmail.com> wrote: Sorry if this is a duplicate, I?m behind on the list by a little. I think the Be Book is effectively on-line at https://www.haiku-os.org/legacy-docs/bebook/ Haiku, open-source and ?inspired by BeOS?, is pretty easy to install on a virtual machine on VMWare or (reportedly) VirtualBox. I don?t know how faithful it is to the original Be experience, but just in case you are interested. - Mark

It was thus said that the Great Liam Proven once stated: The 6908 *is* better than either the Z80 or the 6502 (yes, I'm one of *those* 8-) There are still VxWorks and QNX in embedded systems (I think both are now flying through space on various probes) so it's not quite a monoculture. But yes, the desktop does have severe moncultures. Citation needed. C derivatives? The only one I'm aware of is C++ and that's a far way from C nowadays (and no, using curly braces does not make something a C derivative). They may be implemented in C, but they're all a far cry from C (unless youmean they're imperative languages, then yes, they're "like" C in that reguard). Rust is now written in Rust. Go is now written in Go. Same with D. There are modern alternatives to C. And if the community is anything to go by, there is a slowly growing contigent of programmers that would outlaw the use of C (punishable by death). I seriously think outlawing C will not fix the problems, but I think I'm in the minority on that feeling. While the Canon Cat was innovative, perhaps it was too early. We were still in the era of general purpose computers and the idea of an "information appliance" was still in its infancy and perhaps, not an idea people were willing to deal with at the time. Also, how easy was it to get data *out* of the Canon Cat? (now that I think about it---it came with a disk drive, so in theory, possible) You could word process, do some calculations, simple programming ... but no Solitare. As for CAOS, I haven't heard of it (and yes, I did the Amiga thing in the early 90s). What was unique about it? And as much as I loved the Amiga, the GUI API (at least 1.x version) was very tied to the hardware and the OS was very much uniprocessor in design. To be fair, *everybody* missed the essence of what they did at PARC; even Alan Kay wasn't of much help ("I meant message passing, *not* objects!" "Then why didn't you say so earlier?" "And Smalltalk was *never* meant to be standardized! It was meant to be replaced with something else every six months!" "Uh, Alan, that's *not* how industry works."). The problem with the Lisp machines (from what I can see) is not that they were bad, but they were too expensive and the cheap Unix workstations overtook them in performance. Had Symbolics and LMI moved their software to commodity hardware they might have survived (in this, Bill Gates was right---it was software, not hardware, where the money was). Smalltalk has other issues. In the 80s, there were not many machines capable of running Smalltalk (I'm not aware of any implementation on micros, serious or not) and by the time workstations where becoming cheap enough, the Smalltalk vendors were charging rediculous amounts of money for Smalltalk. The other issue is the image---how do you "distribute" software written in Smalltalk? Smalltalk is the application is Smalltalk, so you have to buy into the whole ecosystem (perhaps in the 90s---today, probably less so). The essence being (LISP|Smalltalk) all the way from top to bottom? I beg to differ. MS-DOS *was* CP/M (or rather, CP/M on the 8086). I've studied CP/M and have had to implement a portion of MS-DOS for a one-off project of mine [1] that used the CP/M era system calls of MS-DOS (MS-DOS later got more Unix like system calls, which are actually nicer to use than the CP/M versions). Because Microsoft and IBM had different goals. Microsoft wanted a 32-bit version initially; IBM did not want to eat into their mini and main frame business and IBM had the clout to push their agenda and thus, OS/2 1.x for the 80286. The partnership soured in 1990, Microsoft went with NT and IBM took over OS/2 but didn't have the marketing clout (or savviness) if Microsoft. The 68k series dies because Motorola could not compete with Intel. Morotola did more than just chips (radios, cell phones) whereas Intel did nothing *but* chips, and with Microsoft pushing computers into every home (a definite goal of Bill Gates, but of course all them running Microsoft software) gave Intel a significant bankroll to make the x86 line performant (and no one really wanted the Intel RISC chips; at least, not to the degree to make continued development profitable). ?Consistent mediocrity, delivered on a large scale, is much more profitable than anything on a small scale, no matter how efficient it might be.? COBRA was dead by the mid-90s and had nothing (that I know of) to do with Linux. And the lumbering GUI apps, RPC, etc that you are complaining about is the userland stuff---nothing to do with the Linux kernel (okay, perhaps I'm nitpicking here). Look at any industry and the pattern repeats. I'm still not convinced Curtis isn't trolling with Urbit. Like Alan Kay, he's not saying anything, expecting us to figure out what he means (and then yell at us for failing to successfully read his mind). -spc (Have dealt with my share of "geniuses" yelling at me for failing to read their mind ... ) [1] https://github.com/spc476/NaNoGenMo-2015 https://github.com/dariusk/NaNoGenMo-2015/issues/184

I've got a set of floppy images of Smalltalk that worked fine on early Macintosh machines - I'm not sure what the oldest one would've been, but I only had Macintosh 512 and Macintosh Plus systems at the time; I seem to recall that it was available as a developer floppy. It had an Apple label. (Note that this is from memory - the floppies are at my home, which is miles from my work...) ----- Original Message ----- From: "Fred Cisin" <cisin at xenosoft.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Wednesday, April 27, 2016 1:25:12 PM Subject: Re: strangest systems I've sent email from On Wed, 27 Apr 2016, Sean Conner wrote: Apple Lisa. Don't know whether it ever went to market.

On Apr 27, 2016, at 1:25 PM, Fred Cisin <cisin at xenosoft.com> wrote: I think both Lisa and Mac Smalltalk went to market, or at least to academia and industry if they weren?t available as products. -- Chris

Sean Conner wrote:on Wed, 27 Apr 2016 16:13:07 -0400 To be fair, the Z80 and 6502 had to compete against the 8080 while the 6809 came out after the 8086 and 68000. Objective-C was the only other C derivative to have a significant impact. CTalk and a bunch of others were mere historical curiosities. The Cat could execute any Forth code embeded in your text document, so it could have had a Solitaire. It was extremely well received by its intended users: secretaries. It was killed off to stop a dispute between the chiefs of the computer and typewriter divisions of Canon and not due to any commercial reasons. You are paraphrasing the "burn the disk packs" discussion at a Learning Research Group retreat. Alan Kay wanted to throw everything away and create a new end user programming system. Dan Ingalls wanted to clean up Smalltalk-74 even if it became harder for children to use it and then implement a system for children on top of that (see Scratch and Etoys). Alan let Dan do it his way (Smalltalk-76), and even supported the attempt go from research to development in the Notetaker project (Smalltalk-78) even though that is not his thing. When an executive from Xerox headquarters flew in just to kill the Notetaker ("Xerox doesn't do microcomputers", he said) Alan left for Atari and the rest of the group decided to create Smalltalk-80 as a software-only product to run on other company's machines. I would say that at the time Smalltalk-80 was the most standard language out there along with UCSD Pascal and with its set of books it was the best documented one. Symbolics moved all its stuff to the Alpha processor, but that was the wrong choice. Note that there were software-only Lisps for workstations like Franz Lisp. Some people, when they hear that I develop Smalltalk computers, like to inform me that there used to be Lisp machines but they failed (for some reason they seem to think I wouldn't know that). Their conclusion is that language specific computers are a bad idea. My reply is that all the generic computers except two (PC and 360) have also died, and one of the survivors is such a tiny niche. As others have pointed out, Apple sold Smalltalk-80 for the Mac. Unfortunately you had to be a registered developer to be able to buy it. A reduced version could run on a Mac 512 but for the full thing you needed at least 1MB. As Smalltalk-80 accessed the hardware directly, it couldn't deal with ADB keyboards (but the mouse worked for some reason). Digitalk came out with Methods for the PC (with at least 512KB) in 1985 and Smalltalk V in 1986. It soon had a Smalltalk V/Mac (which is why Apple stopped selling their own Smalltalk and didn't updated it for newer Macs), Smalltalk V/286 (for a long while the only language to be able to used more than 640KB on a PC) and eventually Smalltalk V/Win. ParcPlace was spun off from Xerox in 1988 and focused on workstations with extremely expensive products (which continues to this day - see Cincom). By the early 1990s there were some more nice Smalltalks for PCs (Object Studio, Dolphin, Smalltalk MT) and Macs (SmalltalkAgents). This certainly wasn't the case for Smalltalk V/Win, but other Smalltalks had solutions for "stripping" and image. Alan Kay makes an interesting comment about Lisp on page 524 (page 15 of the PDF) of "An Early History of Smalltalk": http://www.vpri.org/pdf/hc_smalltalk_history.pdf He had learned Lisp at Utah, but nobody there used it except for teaching so he only learned about CAR, CDR, CONS etc. Only when he spent some time at SAIL (Stanford Artificial Intelligence Laboratory) did he finally get the idea of Lisp and what EVAL and APPLY were all about. I would not be surprised if many students who had Lisp in school and hated it never really got it like Alan hadn't. -- Jecel

It is also the basis for iOS - you know, the system that runs on iPhones. I'd say that would be considered a significant impact - over 1.5 million applications. ----- Original Message ----- From: "Paul Koning" <paulkoning at comcast.net> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Thursday, April 28, 2016 7:58:43 AM Subject: Re: smalltalk and lisp (was: strangest systems I've sent email from) Did it really? It is used in the Mac, much as Bliss was in VMS, but apart from that, would anyone use it? paul

On Thu, Apr 28, 2016 at 10:21 AM, Swift Griggs <swiftgriggs at gmail.com> wrote: I do a lot of iOS development and it took me years to get used to, or at least feel comfortable with, Objective-C. At first I hated how verbose it and Apple's SDKs felt, but appreciate a lot of that now. I'm doing some embedded C++ work right now too, and often wish I could use Objective-C there. I haven't done any C++ in years though, and have found C++11 added some nice things. I'll try whatever is new and fun though, and I've been enjoying Swift (the language!) quite a bit. Apple is pushing it pretty hard, so I'll probably use it for my next big iOS project. -- Ben Sinclair ben at bensinclair.com

What have they added? I recall hearing of someone doing some language that requires a runtime with garbage collection and trying to call it C, which to my mind would be a huge mistake - is that C11? It'd certainly be an interesting experiment to take C and add polymorphism and nothing else. I've occasionally wished for it myself, though admittedly not often - between gcc's additions and my own addition I find it rich enough for most of my purposes. (I really should build my own compiler for it, someday, though.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Fri, 29 Apr 2016, Paul Koning wrote: He *might* also be referring to the part of C11 that folks malign sometimes (Annex K) for bounds checking. Checkout strcpy_s() and strcat_s(). However, maybe not, since it's definitely not GC, just some bounds checking to prevent common crashes & security issues. There is also some rinky-dink GC in C++11 that nobody seems to like or know what to do with: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm Word on the street is that this will get removed. I wouldn't trust it anyhow because it's weird and I'd just ignore it and use boost:shared_ptr with glee. -Swift

Who uses Linux to refer to just the kernel these days? GNOME used (uses?) CORBA - I assume this is what Liam meant. CORBA was standardised in 1997, and had significant momentum up to at least 2000. I'm very happy that there is no chance that anybody will ever be in a position to ask me to work with CORBA again.