Shop OBEX P1 Docs P2 Docs Learn Events
Prop-2 Official Name - Page 2 — Parallax Forums

Prop-2 Official Name

24

Comments

  • Heater.Heater. Posts: 21,230
    potatohead,

    Being able to run Linux/X Windows applications on Windows 10 with the new Linux Subsystem for Windows and an X server is a good trick.

    I don't regard that as a "cross-platform" solution. It's a clunky way to get things running in places they were not designed for.
  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-14 10:37
    Who are you kidding Heater? That is exactly what X was intended for.

    The subsystem is a perfect, headless compute server or node. Pipe it to a graphics system and go. Easy peasy.

    One day, all these gui systems might just catch up with where the brilliant peeps, who gave us X, were decades before.

    Edit: The only reason it seems clunky is so darn many people didn't get a real exposure to X.

    What they got was single user, dedicated graphics nodes. Fine, but X is multi user, multi node, or host. All of that is OS agnostic too. Smart guys back then. Had vision that endures to this day.

    The win subsystem case is ordinary, in that respect. A X user wouldn't even think about it. Just run a server and go.

  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-14 10:38
  • Heater.Heater. Posts: 21,230
    edited 2017-10-14 10:42
    potatohead,
    Who are you kidding Heater? That is exactly what X was intended for.
    Traditionally "cross-platform" was about that ability to use the same source code on multiple different machines/architectures/operating systems.

    That is why the fetal Unix was rewritten in C. So that it could become a cross-platform solution and spread around.

    So, taking "cross-platform" literally I don't regard building and running a program on one machine and displaying its output on another, different, machine as cross-platform solution.

    X is a wonderful thing and all but I have issues with your suggestion:

    1) Is it even possible to run 3D accelerated graphics over a remote, network, connection? On the rare occasions I have used X over a network connection it was unbearably slow even for regular software that did not need a GPU.

    2) What about audio?

    3) What about access to serial ports and other hardware?



  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-14 10:51
    1) Yes, I was doing it in the 90s at speeds you would not believe, on IRIX, 10T Ethernet, GLX extensions, High end solid modeling software.

    I could put a big chunk of a car on the screen and go to town.

    This did require an application developer to grok the system and allow OGL to do its thing. Apps today are crappy. Will work on a local, or high speed network. Anything else is a mess.

    But, local X server in this case will be fine.

    2) a mess. I do not understand how audio didn't get done X style. Audio is consistently painful on most things today.

    3)X supported a lot with extensions. Google multi head. IRIX had it all built in, optimized. One common use was a shared station, one Onyx, several users, keyboards mice. Another was the VR wall type installations, multiple display nodes, mosaic style.

    Is possible to have a lot of input devices associated with a display host. High end apps on SGI did just that. Buttons, dials joystick, mouse, keyboard...

  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-14 10:46
    By the way, if you have hardware access in your headless environment, there is no need for the graphics server to get involved. It just does a gui.

  • X was intended as multiplatform OS agnostic graphics, UI, BTW. It's a service, not an app, not a library.
  • Heater.Heater. Posts: 21,230
    potatohead,

    Typically that is the only time I want to use X remotely for long time. There is some headless system, no display, keyboard, mouse etc. And I want to run some GUI application on it with it's display on my PC/laptop. Typically this has been so slow that I would not imagine trying to use it for long term serious use.
    X was intended as multiplatform OS agnostic graphics, UI, BTW. It's a service, not an app, not a library.
    As such it is brilliant. Back in the day our Unix based schematic capture and PCB layout suite ran on some Sun, Apollo or whatever machine and could displayed itself on our MS-DOS PC's.

    From the point of view of writing a GUI app it makes no odds if the graphics system is a service or a library, server or client. There is an API for my app to use and I just want it to work. For example, my Qt based applications run on Windows where it has direct access to the graphics via Windows API and libraries. Or they run on Linux where they talk to an X server.


  • evanhevanh Posts: 15,126
    There's clearly some differing perspectives here. Certain terms mean different things to different people. I think I'll be signing off on this topic.
  • SeairthSeairth Posts: 2,474
    edited 2017-10-14 13:23
    Heater. wrote: »
    .Net Framework - Develop high performance applications in less time, on any platform. By Microsoft.

    More accurately, .Net Standard is the cross-platform specification, .Net Core is the open-source, cross-platform implementation of .Net Standard, and .Net Framework is Windows only implementation (that also implements .Net Standard). And there's always been Mono, which was a cross-platform port of many parts of .Net Framework. With the introduction of .Net Standard (and the .Net Core implementation), Mono has been realigning itself to .Net Standard and replacing much of that portion of the code with the same codebase used by .Net Core. The point is... if you target .Net Standard, you can run on any platform that has a current .Net implementation.
    Heater. wrote: »
    Node.js - Javascript run time (Microsoft)

    Not a Microsoft product.
  • Wait a minute... what does all of this have to do with the original topic?
  • Heater.Heater. Posts: 21,230
    edited 2017-10-14 13:45
    Searith,

    Exactly. The .Net standard enables one to write cross-platform software. As does Java, Javascript, Python, etc.
    Not a Microsoft product.
    Might be. Especially when it is supplied my MS and uses the MS Chakracore Javascript engine rather than the usual Google V8 engine of original Node.js.

    https://blogs.windows.com/msedgedev/2017/07/27/node-chakracore-update-n-api-ios/
    https://github.com/Microsoft/ChakraCore/wiki/Roadmap
    Wait a minute... what does all of this have to do with the original topic?
    No idea. What was the question?


  • Seairth wrote: »
    Wait a minute... what does all of this have to do with the original topic?

    My sentiments exactly. When users from outside come to read this topic, they are provided with talk about .NET, JS, Linux, X.... which has nothing to do with the original thread topic.

    We are way off topic here.

  • Heater.Heater. Posts: 21,230
    Well, Phil suggested "viimeinen potkuri"

    Which sounds a bit depressingly pääte to me.

  • Same. Didn't mind burying that.

    As for the name...

    Smart Pin Propeller

    That is the primary difference. Put it in the name.

    Re: X

    Sorry, I'll tend to go on about X. Many, many misconceptions. I'll hold my direct access to graphics comments for another day, save to say we live with screen scrapers and crunchers... ugh.
  • Or Propeller Turbo with Smart Pins
  • Heater.Heater. Posts: 21,230
    I think, basically, the whole problem that X was designed to solve is non-existent today. If it was ever a problem for the majority of computer users.

    Here we are, having a discussion. The server handling this discussion is God knows where. The machine handling the graphical user interface is right here, under my nose. Or there, wherever you are.

    The web of HTTP and HTML renders all that X stuff irrelevant.

    Who would be crazy enough to try and build what we have here, now, using X?

    My humble home router has a web interface. Not an X interface.

    My databases in the cloud have a web interface. Not an X interface.

    And so on.

    Why do we need the X network protocol?

  • potatoheadpotatohead Posts: 10,253
    edited 2017-10-14 22:36
    Lol, what they will do is reinvent it. JS can deliver rich experiences today. Just needs a little standardization and an easy to setup and run server.. hello X!

    See, a network protocol works for all but the most demanding local graphics. And, frankly, the performance hit with a well designed TCP stack, like SGI did, is competitive with pipes, and other schemes.

    The bonus is rich interactivity no matter what talks to what.

    Edit: Starting another thread. In gen discussion.

    You just watch. :D (Not for the thread. For X being reinvented, just like UNIX often does.)
  • Heater.Heater. Posts: 21,230
    OK. Standing by.
  • Back to original topic
    Propeller 2 - P8X64SP ?
  • I like it for a part number.

  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    Back to original topic
    Propeller 2 - P8X64SP ?
    I think Chip has already chosen a part code ?
    To me P8X64SP does not make much sense, as the part is not 64 bit, and the package is not 64 pins, and the IO count is
    never usually part of a part number... - users expect to see Code Size, and package suffix in part numbers.

    If Parallax makes a 32 Smart pin version, that becomes P8X32SP. I can see a problem already.... ;)

    .. but P2 does need an over-arching, easy to remember name, that can google-find. 'P2' fails that test.


  • Well if it's a Propeller that's jet-powered, then it's a TurboProp.
  • jmg wrote: »
    ozpropdev wrote: »
    Back to original topic
    Propeller 2 - P8X64SP ?
    I think Chip has already chosen a part code ?
    To me P8X64SP does not make much sense, as the part is not 64 bit, and the package is not 64 pins, and the IO count is
    never usually part of a part number... - users expect to see Code Size, and package suffix in part numbers.

    If Parallax makes a 32 Smart pin version, that becomes P8X32SP. I can see a problem already.... ;)

    .. but P2 does need an over-arching, easy to remember name, that can google-find. 'P2' fails that test.
    IIRC P2Hot had the part number P8X32C.
    That didn't really highlight the massive differences from the P8X32A either.

    Luckily Parallax doesn't need a convoluted product selector like the "pthers".
    You can have a Propeller 1 or a Propeller 2, nice and easy. :)



  • Had they stuck with "nice and easy", the Propeller 1 would have been called Basic Stamp 2.

    The Prop-2 is probably just a temporary code name.

    It's really a far different chip than the other Parallax microcontrollers. The developers seem to have an interest in aerospace propulsion. There are propellers, turbo-props, turbo-fans, turbojets, ramjet, and the mother of all jet engines, the scramjet.
  • kwinnkwinn Posts: 8,697
    tryit wrote: »
    Had they stuck with "nice and easy", the Propeller 1 would have been called Basic Stamp 2.

    The Prop-2 is probably just a temporary code name.

    It's really a far different chip than the other Parallax microcontrollers. The developers seem to have an interest in aerospace propulsion. There are propellers, turbo-props, turbo-fans, turbojets, ramjet, and the mother of all jet engines, the scramjet.

    The Propeller 1 was anything but Basic so Basic Stamp 2 would have been a major misnomer. With both P1 and P2 being multicore microcontrollers I don't see anything wrong with using the number of cores and I/O pins as part of the designation. Sometimes the simple and obvious choice is best.

    PS - not that I really care what the designation is as long as I can buy a few.
  • You'd think after 12 years of development, the Prop-2 would be a major advance since the Prop-1, just like the Prop-1 was over the Stamp.

    You and I may not care about the designation, but from a marketing perspective, a proper name is of paramount importance.

    I think Prop-2 will do fine with current Parallax customers. But if you want to go after Raspberry Pi and Arduino customers, Parallax had better make a compelling story. Perhaps consider making the Prop-2 compatible with the Arduino IDE and the C-programming environment. I'm not saying getting rid of Spin, but I'm saying expand your customer base.
  • kwinnkwinn Posts: 8,697
    tryit wrote: »
    You'd think after 12 years of development, the Prop-2 would be a major advance since the Prop-1, just like the Prop-1 was over the Stamp.

    You and I may not care about the designation, but from a marketing perspective, a proper name is of paramount importance.

    I think Prop-2 will do fine with current Parallax customers. But if you want to go after Raspberry Pi and Arduino customers, Parallax had better make a compelling story. Perhaps consider making the Prop-2 compatible with the Arduino IDE and the C-programming environment. I'm not saying getting rid of Spin, but I'm saying expand your customer base.

    From a marketing perspective I would hope that a good description of things like the multiple cores, smart I/O pins, deterministic timing, video capability, and other features of the architecture would make a compelling story.

    Programming in C is already in the works, but why cripple a multi core cpu with an IDE for a single core chip?
  • Heater.Heater. Posts: 21,230
    Why do you imagine that an IDE limits one to a single core?
  • kwinnkwinn Posts: 8,697
    Heater. wrote: »
    Why do you imagine that an IDE limits one to a single core?

    It may not limit you to a single core, but it does not do anything to make use of multiple cores easier either.
Sign In or Register to comment.