PDA

View Full Version : Open-sourced Propeller Windows IDE - very possible, but helpful?



Ken Gracey
12-12-2009, 04:09 AM
Hey all,

Providing you with some insight about what we're thinking of doing ahead of time with the Windows Prop IDE. Having spent the last couple of days researching various aspects of open source I now know less than when I started looking around. I'm not a programmer, nor am I experienced with open-source licenses, so you'll need to add a bit of your own interpretation to what we're going to propose. Chip and Jeff are busy doing other development work today, so you get me.

If we open-sourced our Windows Propeller IDE it would provide enough information to aid developers in creating some entirely new programming tools. This is what could be released under one of the Creative Commons licenses:

- Delphi code
- compiler assembly language source code
- Spin interpreter (posted somewhere in the forums already)
- Propellant library

That's the whole software side, well almost.

The Delphi code uses several licensed components from elsewhere, which may not have open license arrangements that allow us to redistribute them as source. We would identify those code segments and their purpose. This means that developers with the right Delphi tools wouldn't be able to produce a complete compiled IDE from our source download because they'd be missing components that we have no license to redistribute.

As Chip puts it, the compiler assembly language source code would also be "pretty complicated" to understand. Again, not sure how useful this would be either.

All Parallax would retain at this point would be the Propeller silicon, but enough code would be provided that creative developers would be able to create tools for even more obscure platforms, like a Blackberry or smart phone. Existing developers would have less reverse-engineering to achieve their tools and they would be able to call upon other forum members for help, too.

Such a release would have to entail a few "gotchas"m. First, Parallax wouldn't answer any questions about what has been released. At the moment we respond to every e-mail, but this effort couldn't include that kind of support. We would also not want to be obligated to review or use any IDE improvements that are created for our Windows Prop IDE. If we near this kind of support obligation we won't be able to release new Propellers or improvements to our own Windows Prop IDE. I can't emphasize the importance of this point. We're a small company.

This also introduces some risk for us in terms of the integrity of the whole product line from the newcomer's perspective. For example, if an improved Propeller Windows IDE collected up archives differently, or utilized different methods of compiling code, then our OBEX library may not work as intended with the variant IDE. Newcomers to the Propeller could be faced with the same kind of disgust we all know too well. We never want to sacrifice the functional simplicity that we offer today. In Parallax we hold disdain for tools (CAD, PCB layout, software development tools, whatever) that don't readily compile code, or that choke on file compatibility because of forced upgrades. Any engineer at Parallax who needs to configure a new PC takes weeks to get things straight again ($150/hr x 8 hrs x 16 days). We want nothing to do with these problems, nor do we want to partake in their existence. For example, our BS2 interpreter remains unchanged since 1995 except for some minor bits flipped for new versions of a PIC. Dozens of new Stamp IDEs were released in this period. We want our customers to have a positive, quickly-working experience without compatibility problems.

It would be our hope that a release as we are considering would aid the development of other tools. From our perspective this is the biggest reason to be more open.

We are still reviewing the various Creative Commons licenses to see which one suits us best.

Future versions of the Prop IDE would be released in the same way, too.

I'm not even certain that this kind of release would even be useful, but it's the casual request in the PropScope threads that caused me to look into it more deeply. If it helps Brad with BST then I consider it worthwhile, and especially useful if it enabled the creation of more tools and downloaders for other devices. For example, Tracy Allen made the "Stache" Field Programmer for the BASIC Stamp with similar information.

Hopefully answering the request for open source isn't akin to responding to common complaints that occur on forums just because something doesn't exist but somebody thinks it should - and it ultimately makes no difference to Parallax's business (or your business) - then we shouldn't bother with the effort.

I just want to try to give you a look into our thoughts on the idea. I'll count on all of you to make light of the topic and have a bit of fun with the idea. Poking fun is welcome! Feel free to be constructive and critical - I made this post to get your input. Please don't take this post as a promise to release.

Sincerely,

Ken Gracey
Parallax Inc.

P.S. I'll be traveling to Minn - St. Paul Sunday through Monday (a project all of you will appreciate) so this thread will bake without my attendance. I'll check in as time permits.

Post Edited (Ken Gracey (Parallax)) : 12/11/2009 8:28:42 PM GMT

Javalin
12-12-2009, 04:25 AM
Ken,

IMHO - don't give away the farm. You've done far enough by providing the propellent library - anybody can write a IDE to run with that.

James

rokicki
12-12-2009, 04:34 AM
I sort of concur. I think getting the ASM code released somewhere, to someone, where they could make a 100% work-alike in C, C++, Java, or some other language,
*might* be worth doing, but I'm not sure it needs to be fully open-sourced.

I think Parallax will be h ard-pressed to depend on someone else to develop the full IDE in a timely and bug-free fashion, and yet a huge part of the prop is just how easy
and intuitive the IDE is. (You can see I am already looking ahead to the Prop 2).

But a relatively small, clean, Propellant work-alike in C or Java or C++ would be an excellent starting point for others, who may over time integrate it into Eclipse or
build a hand-crafted GUI using fully open-source tools.

I recommend thinking carefully about the license, and choosing one that has stood the test of time. The Apache license is probably a good one to consider, allowing both
commercial use and non-commercial use.

I think released GUI/IDE code is probably not that useful, especially if it's encumbered by dependencies on non-open-source.

The problem I see is as the IDE is open sourced, people will develop extensions that the community will clamor for, and not having them in the default Parallax IDE
will fragment the community. We should strive for a model where enhancements can be fed back to Parallax (with full backwards compatibility maintained forever
of course), perhaps with a community vetting committee or period so Parallax doesn't spend forever dealing with controversial changes. I believe the dominant
such changes will be enhancements to Spin and/or the assembly compiler, and not affect the UI at all.

mctrivia
12-12-2009, 04:40 AM
Though I know delphi I avoid x86 assembly so it would not help me. Now a rewrite in java would be extremely helpful because it would be easy to port to different os including blackberry.

Now if you did publish the code I am sure someone would take the challenge to convert to java.


As for obex you would probably have to implement a 4th language option. Xpasm as more code would come out with optional tags that the current ide does not support.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder. (http://forums.parallax.com/showthread.php?p=848975)

Nick McClick
12-12-2009, 05:10 AM
What hurts most is official Mac support - I haven't heard any complaints about the license, but plenty of people have turned away at the lack of Mac support. I wouldn't complain if you use a more 'open' license for the Propeller tool, but what will help me sell more Propellers most is supporting other OS'es.

It's okay if this helps 'unofficial' Mac support, but there needs to be a link on the Download page to a Mac client.

There's already better feedback in this thread, but that's my 2 cents.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed! (http://www.nicholasm.com/proprss/)

Gadget Gangster - Share your Electronic Projects (http://www.gadgetgangster.com)

Luis Digital
12-12-2009, 05:43 AM
Ken,

You made the question and provided the answer: Useful for improving or creating other tools.

As for support, simply add a note saying it is available as is and there is no official support.

Phil Pilgrim (PhiPi)
12-12-2009, 05:47 AM
Ken,

OBEX compatibility is a major issue. I think you will end up requiring that all submissions to the OBEX have to work as advertised when compiled with the official Parallax IDE. This places an extra onus on tool developers, in that they will have to provide a converter that translates any language extensions back to vanilla Spin and assembly code. It also sustains the pressure on Chip and Jeff to provide the "official" IDE and language with the features that customers demand. (For this reason, I really hope there's no Prop III on the horizon, so they have time to address things like this. http://forums.parallax.com/images/smilies/smile.gif )

-Phil

BradC
12-12-2009, 06:15 AM
Javalin said...
IMHO - don't give away the farm. You've done far enough by providing the propellent library - anybody can write a IDE to run with that.


Err.. no. Anybody running Microsoft Windows can run an IDE with that. Those of us who don't use that particular operating system were still pretty much out in the cold.


Nick McClick said...
What hurts most is official Mac support - I haven't heard any complaints about the license, but plenty of people have turned away at the lack of Mac support. I wouldn't complain if you use a more 'open' license for the Propeller tool, but what will help me sell more Propellers most is supporting other OS'es.


It always saddens me to read comments like that...


rokicki said...
I think getting the ASM code released somewhere, to someone, where they could make a 100% work-alike in C, C++, Java, or some other language,
*might* be worth doing, but I'm not sure it needs to be fully open-sourced.


This is a key point. The compiler *is* a complex piece of code, and to follow it does kinda tie you in a knot. It's a wizard piece of programming though. Having the source available for a couple of people who would find it useful is a great idea. Even if not directly useful, it would be great reference documentation and it completes the picture started by the interpreter source.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Ken Gracey
12-12-2009, 06:19 AM
@BradC. Me too regarding your second point. Ouch! Whack!

You can have whatever you need from us regardless of what we do for the whole customer base. If any of the stuff we mentioned above is helpful for BST, just ask me in the meantime.

Ken Gracey
Parallax Inc.

Nick McClick
12-12-2009, 07:10 AM
@BradC - I think BST is awesome and I always point people to it when they ask about mac support. Maybe a link to it on the downloads page (http://www.parallax.com/tabid/442/Default.aspx)?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed! (http://www.nicholasm.com/proprss/)

Gadget Gangster - Share your Electronic Projects (http://www.gadgetgangster.com)

Luis Digital
12-12-2009, 07:31 AM
Ken Gracey (Parallax) said...
@BradC. Me too regarding your second point. Ouch! Whack!

You can have whatever you need from us regardless of what we do for the whole customer base. If any of the stuff we mentioned above is helpful for BST, just ask me in the meantime.

Ken Gracey
Parallax Inc.


BST is not open source, if for some reason stopped developing the program, then it will work lost because no one can continue the work.

BradC
12-12-2009, 07:43 AM
Luis Digital said...

BST is not open source, if for some reason stopped developing the program, then it will work lost because no one can continue the work.


You are both right and not entirely correct on those points.

Yes, bst is currently closed source and will continue to be as long as I'm really enjoying developing it (or I get the code cleaned up to a point where I think its not a complete pile of spaghetti). I have always said that if, for some reason I no longer wish to, or cease to be able to support the code I would release it all for someone else to take up the baton.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Luis Digital
12-12-2009, 07:59 AM
Spaghetti?
Nobody is perfect, but you're a genius. Do not be afraid of her spaghetti. xD

Dr_Acula
12-12-2009, 08:34 AM
I'd have to agree with several previous posts suggesting careful consideration before making this open source.

Maybe I'll start with two real world practical examples and see where it leads:

1) The Zicog project with at least 4-5 people all working together but pushing in different directions at the same time. Rather than force people to use one set of code, a solution has been to use #ifdef commands to turn on and off code for different hardware. The Propeller IDE does not support #ifdef but BST does, so the Zicog is BST compatible but not compatible with the standard IDE. I'm not sure the Zicog would have been possible on the standard IDE?

2) Writing huge spin/pasm programs. Eg a 200k program. There are now a number of hardware platforms that have access to large memory chips. There is software that puts overlays in and out of cogs and stores the overlay data in hub memory, so there is no reason you can't put overlays in and out of hub memory and store the data in external ram. There are a number of ways to write a 200k binary that is self contained in the way it moves bits of itself in and out of hub ram. But to work on a propeller it would need to be split into a smaller bit that sits in eeprom and a larger bit that might be read from an sd card into ram. What would be very useful is to have an IDE that just has reams and reams of spin code, and you hit F11 and it sorts out the compilation in the background and makes it run. Right now that doesn't exist but it could if the source code was available.

Having said all that, I have some concerns about releasing too much code out into the wild. I'm thinking of the Picaxe story where we are starting to see 'clones' appearing. So far, those clones are not proving very popular as they have poor technical support, rather thin help manuals and no supportive forum. But clearly there are people who see a big enough market that they think it is worthwhile trying to clone a successful product.

I don't think you want to make it too easy for cloners. Right now the prop is harder to clone as you would have to copy both the silicon and the software. If you make the software open source, then it is just the silicon. I find it fascinating the story of how the East Germans and Russians cloned the Z80, and it is even more interesting discussing Z80 and CP/M projects with people who built these in Russia in the mid 1980s and who know the chip backwards but have never seen nor coded on a real Z80 chip. Bottom line is that silicon can be copied.

I'm wondering if there is another option?

If you put the zip of the source code on a website there will be some expert programmers who will download it and make it better. But there will also be some amateurs who download it, hack it a bit and risk splitting the language into a myriad of dialects. And it gives a free leg up to the cloners.

I think the people who could improve the code are already well known to the community. I'm wondering about only releasing the code to people who have proved their credentials in some way on this forum? They have shared code. They have given as much as they have taken. They have written code that others have said is well written and easy to understand.

I'd humbly suggest restricting distribution to just those people. I don't think that would be an onerous restriction as any/all the people keen to improve the IDE would already pass the test.

Even then, it still is worth thinking about preventing cloining. When I purchased a licence for Eagle PCB they asked me to fill in and sign a form to say I would not put the program on a file sharing website. They also said that the program contained a unique key and if they ever did find a copy on a bittorrent site they could track it back to me. I feel that is an entirely reasonable way to protect the IP and the jobs of all the people who work in that company (plus the ongoing improvements to the software) and all it cost from my end was my signature on a piece of paper and the cost of an international fax.

Even if you do release the source code, I wonder about having a tiny compiled program that is essential to compiling the code in some way and you keep that program secret and have some sort of unique number in that program that the end user is responsible for?

So, rather than releasing the entire source as open source, I wonder if you could consider an arrangement where you might have a small number of trusted people who have access to the source? These people might even have a commercial interest, eg I might put a post on the forum saying "who could code me xxx in their compiler for yy$". But at the same time those people are unlikely to give away their program or source.

Just thinking aloud here, but what would be the chances of a Prop III if you could buy a cloned propeller with free software on ebay for $2?

Of course, these are just my opinions and parallax can do what it wishes, but I'd very much support keeping this discussion going for a while before any decision is made.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller (http://www.smarthome.viviti.com/propeller)

Roy Eltham
12-12-2009, 08:45 AM
I think this is a good idea for you guys to pursue. The long term benefit derived from the community of people taking it and doing great things will be giant.
I would encourage you to pick as open or free a license as possible to allow people the freedom to make anything from it. However, I am strongly against GPL or it's variants. It's just to restrictive.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

evanh
12-12-2009, 09:02 AM
Dr_Acula said...
I don't think you want to make it too easy for cloners. Right now the prop is harder to clone as you would have to copy both the silicon and the software. If you make the software open source, then it is just the silicon. I find it fascinating the story of how the East Germans and Russians cloned the Z80, and it is even more interesting discussing Z80 and CP/M projects with people who built these in Russia in the mid 1980s and who know the chip backwards but have never seen nor coded on a real Z80 chip. Bottom line is that silicon can be copied.

Your argument is flawed. The software is the easy part. What's more, they don't bother to work with source code, they just run the exact same binaries. That's why it's called a clone.

One can't expect to hold a monopoly on one design forever. Especially a popular one. Move forward.

mctrivia
12-12-2009, 09:05 AM
Dr_Acula I don't think the clone problem you mention is an issue for 2 reasons.

1) The IDE is free.
2) Most of ROM including the SPIN Interpreter is already known and available.

If you were willing to put the money in to cloning the silicon then you could just use the existing IDE and ROM data. It would be a hugely expensive pursuit to clone the prop and since the chip only costs $8 you would not be able to make much since you would have to sell the clone for at least half.

People have already started to try and reproduce the cogs on FPGAs for the fun of it but you will never get the energy efficiency, cost, and density on an FPGA as you will using the real prop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder. (http://forums.parallax.com/showthread.php?p=848975)

evanh
12-12-2009, 09:05 AM
Regarding the Picaxe - they are paid to produce for the UK education market. Just because the Picaxe uses a similar BASIC to the Stamp doesn't make it a clone.

Chris_D
12-12-2009, 09:05 AM
I can understand Parallax wanting to "open things up a bit" to allow other developers to create new products to enhance the Propeller.· It makes good business sense.· I own Viewport and find it to be of GREAT value while programming and debugging.· If other tools come along that can enhance productivity like Viewport, I like the idea of making it "open".·

I can easily see it turning into a great big ole can of worms too.· I have only been around here for 6 months or so and the one thing I found out very quickly is that all the Parallax people bend over backwards to help customers.· Turning off that "culture" for just the open source stuff is going to be very difficult to do - you guys (and gals?) are just too eager to help (which we all love).

Personally, I just don't get the people that buy Macs or Linux machines and are surprised when they find out that not all software titles are available fore their OS.· Most people would agree, Windows isn't great, what is great is the amount of software (and other products) that is available to run in Windows.· In the area of what we all do (programmers), you would think people would be smart enough to know that not all software is available for all operating systems.

Chris

evanh
12-12-2009, 09:13 AM
Chris_D said...
Personally, I just don't get the people that buy Macs or Linux machines and are surprised when they find out that not all software titles are available fore their OS. Most people would agree, Windows isn't great, what is great is the amount of software (and other products) that is available to run in Windows. In the area of what we all do (programmers), you would think people would be smart enough to know that not all software is available for all operating systems.

Surprised? No. Disappointed? Yes. Encouraging support? Absolutely. :)

Ken Gracey
12-12-2009, 09:41 AM
The father of the PICAxe is Clive Seager, and we've communicated in the past. Clive originally authored a BASIC Stamp 1 downloader for the UK's Acorn style machines, about ten years ago. Then (this is stretching my memory so I may be totally wrong in case I'm corrected), through the Technology Enhancement Program (TEP) funded by a UK supermarket chain he broadened his entire educational program, resulting in the PICAxe. Though we were part of his early experience in education, the PICAxe is his entire original work - nothing Parallax provided aided the development of that product.

Therefore, it is not an example of a BASIC Stamp variant that was introduced by Parallax being so IP-loose that our brains fell out. Not a clone. Not sure what "variant" means as used above.

Ken Gracey
Parallax Inc.

Cluso99
12-12-2009, 09:42 AM
I am going to consider my comments carefully before posting a proper reply. However, there are a few comments that I would like to say now.

Chip released the Interpreter source code. Hippy was the expert who unravelled much of the interpreter before this. Now we have the real interpreter, it has enabled us to see what the interpreter is actually doing. I have produced a version which runs about 20% faster, but in my later quest for speed introduced a bug(s). I found other things to do with the prop before completely debugging it - at the time it was a spin/pasm debugger to find the bug. This code is on the forum.

So, what I am saying, is that the release of the Interpreter code did not result in a plenthora of other versions. This code most likely aided Brad and Michael in their compilers. Certainly, their job would have been much simpler if the compiler code was available.

The other possibility I want you all to consider... Do we want "spin" on other hardware?
FOR: Makes the language more universal. AGAINST: Competition to the Propeller hardware.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)
· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Michael O'Brien
12-12-2009, 09:57 AM
Ken,
Sounds like a very useful idea - a process and structure not to be taken lightly. Thank you for bringing it to our attention early in the process.
I really like Parallax - I hardly ever visit a physical electronics shop anymore, I really like the Propeller, and I really like the propeller IDE and Propellent and the way things currently are - however, in light of all the extensions by the developers you name in this post the product is expanding and could go in a lot of very interesting directions. I personally would be also interested in a Java platform port as the main open source project, sub-project or incubator project.

In the corporation i develop with we recently open sourced one layer in our Java SE/EE product lines in 2007 under the Eclipse EPL (http://www.eclipse.org/legal/epl-v10.html) - becoming committers to Eclipse. Just an idea but there is a very diverse ecosystem of projects at Eclipse (and Apache as well). The structure of projects is tree based, for example our product is part of the RT (runtime) project because it is an integration API as opposed to an IDE.
As Rokicki states, Eclipse is also a design-time IDE API that can be leveraged to do the heavy lifting for Linux or Windows system windowing API's - with the javax.comm API available for port communication.

Some open source software for hardware projects of interest

Another related open source hardware platform is the Sun Microsystems Sun Spot - although the kit is kind of expensive and it not currently available.
https://spots.dev.java.net/
http://www.sunspotworld.com/about.html

Note: of particular interest is the DSDP/DD/MultiContext project which involves support for debugging multiple cores.
DSDP: Device Software Development Platform - http://wiki.eclipse.org/DSDP
+-- Target Management (TM) 3.1.1 - http://download.eclipse.org/dsdp/tm/downloads/
+-- Tools for Mobile Linux (TmL) 0.3 - http://download.eclipse.org/dsdp/tml/downloads/
+-- Mobile Tools for Java (MTJ) 1.0 - http://download.eclipse.org/dsdp/mtj/downloads/
+-- DD: Device Debugging project 1.1 - http://www.eclipse.org/dsdp/dd/
------+-- Spirit (target board discriptors) - ARM - http://wiki.eclipse.org/DSDP/DD/Spirit
------+-- MemoryView (IBM/Freescale/AMI) - http://wiki.eclipse.org/DSDP/DD/MemoryView
------+-- DisassemblyView - http://wiki.eclipse.org/DSDP/DD/DisassemblyView
------+-- DSF (Eclipse debugger integration) - http://wiki.eclipse.org/DSDP/DD/DSF
------+-- GDB/DSF debugger integration - http://wiki.eclipse.org/DSDP/DD/GDB
------+-- MultiContext (simultaneous debugging of multiple cores/threads) - http://wiki.eclipse.org/DSDP/DD/MultiContext

Virtual Prototyping Platform (VPP) - merged into DSDP above - sponsored by Xilinx
http://www.eclipse.org/proposals/vpp/

Just some points to assist/aide in your triage of the issues.
thank you
/michael

Post Edited (Michael O'Brien) : 12/12/2009 2:04:26 AM GMT

Kye
12-12-2009, 09:58 AM
More library drivers need to be written for the propeller chip, I've been helping out on that. And then in the summer of 2010 I will be coming out with something that might greatly boost sales hopefully if I can complete it by then...

Honestly, please provide support for multiple OSes, that would be great.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 12/12/2009 4:02:17 PM GMT

W9GFO
12-12-2009, 10:35 AM
My feeling is that, if there is a choice, develop in such a way that the code could be ported to other platforms. Parallax could then share their code with anyone who convinces them that they will do good things with it (like BradC). Pretty much what Dr_Acula said eleven posts up.

Rich H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Simple Servo Tester, a kit from Gadget Gangster. (http://www.gadgetgangster.com/206)

Mike Green
12-12-2009, 11:23 AM
Perhaps people should register for access to the source code. It's not enforcible, but at least people would have to click through a page with the rules on it. Registration could also provide access to a special forum for registered users only to share information. It would not be visited by Parallax personnel except for administrative purposes (like to deal with spam and spammers) and no technical questions would be answered by Parallax.

1) Parallax provides source code and other non-public documentation for informational and educational purposes only.

2) Parallax provides no support for use of the source code. In particular, people should not call tech support or post questions about the source code on the public forums.

3) Parallax provides no support for any binary form of the source code other than that provided by Parallax (because Parallax has no control over the compilation process or the run-time libraries used).

4) Anyone using the source code in a product should make it clear to their customers that Parallax does not provide support for the product.

The above would be included in the source files as part of the license.

People of course can ignore any of the above, but at least Parallax has a basis for refusing to provide support.

NetHog
12-12-2009, 12:05 PM
I think Mike has some good points here.

stevenmess2004
12-12-2009, 12:33 PM
I don't know that opening it up to everybody will really help that much. Probably the only people that would really benefit are people like Brad, ImageCraft and others that are working on compilers. It might be better to limit it to only them and then give them some support rather than opening it up to everyone and offering no support. That would probably give the most benefit to the entire community. For people who have only a casual interest in the compiler there is sphinx which runs on a prop that is probably more fun to play around with.

potatohead
12-12-2009, 01:41 PM
I agree with a covenant of some kind at this point.

There are too many variables, and the Propeller product is in it's life cycle prime right now.

These things are perfectly enforceable with an actual binding contract, not some click through, or sign up, if you agree kind of thing. Also, I think it's important to consider about licenses is the rights holder can issue whatever licenses they want to issue. It's a given that one size does not fit all, so don't do that.

Here's a contrary set of examples. (I too dislike the GPL, but am compelled to post this anyway because the GPL, if used at all, has some serious merits.)

So, author A produced something and licensed it under GPL, forcing all derivatives to be GPL also. That's the bad viral thing nobody likes.

A GPL community forms and integrates this work into the body of GPL code, and life is good for those guys, but....

Commercial efforts, seen as friendly and mutually beneficial, are hobbled by the requirement to GPL derivatives, customers are also hobbled by this.

The originator offers alternative licenses, for commercial use that permit derivatives, and does this for a fee. Could be a small fee, and an actual binding contract. Closed commercial products are released right along side the open GPL ones, and everybody is happy.

If control over what kinds of derivatives is desired, this is actually not a bad scenario. There will exist a pool of open code, and various solutions that are closed. Open innovations can compete with the closed ones, with the technology originator profiting in either case.

Either party may fork the code, and that can compete as well, with the open one always being open, and closed forks being open or not, as the technology originator sees fit as they are bound to honor license terms granted to licensees, but not themselves bound as they own the tech.

So, that's one scenario.

Another one might be to strike a covenant where code is open only for the purpose of mutually beneficial derivatives. This too should be done for a fee, maybe a small one, associated with a binding as in signature and witness contract. The license terms can be whatever makes sense, but for the right to redistribute source code, keeping the body of code in the family, so to speak.

One advantage of this scenario is it does leave an open license of some kind in the future. What the licensees pay for, and if desired only pay enough to make the contract solid, is access on their time frame, and some assurance of access. Those doing open development wait until such time as that becomes an option, and the kind of development will depend on the open license released. Frankly, the GPL has control advantages here too, but is not mandatory. The simple MIT license, time delayed to favor those aligned with Parallax and who share the same longer term interests would not be impacted at all, and see a significant advantage over others.

Where fear of clones is concerned, that's a reality no matter what license, if any, is issued and to whom. Enough exists right now to clone things, and even leverage the software that exists now. That boils down to simple risk / reward, like any security problem does. There is no absolute security, only risk / reward.

So then, the latter approach taken later in the product life cycle has clear advantages as the risk / reward is kept favorable to Parallax during the early time. Risk grows somewhat, but then a new product release largely mitigates that, and worst case, a successful clone will be one generation behind, which is always the best defense. Out innovate them.

Seeing as how Prop II is beginning to enter the field of view, this kind of thing makes sense.

In terms of code being written here in the public eye, the MIT license adds a hell of a lot of value to the Propeller. We all contribute, and we all get more out of it than we put in. (arguably, not literally as there are some where I'm not sure that's the case, and I'm not sure they care either...)

Where the core technology is concerned, I would be concerned about an open MIT release, because that does grant any and all comers permission to do as they will, with no real value in return for Parallax.

The real value is in complimentary efforts, and those can be done without a broad, shot gun style release. I would advocate GPL for that, as it is backed by organizations willing to enter court for infringements, and the only people with blanket permission are those also building open tools, meaning any innovations would be visible to all involved. That keeps any one party from taking over the source of the tech.

The MIT license does open the door for a successful entity to dominate with permission, and if it were me, I'm not sure I would want to do that, given there are lots of alternatives that get everybody taken care of, without seriously leaning that risk / reward ratio out of favor for Parallax. The more I think about the longer term ramifications, the less I like MIT, or Creative Commons for core code releases. Documentation, user authored objects, and other things make great sense, but not for the core code being discussed here.

Despite the scenarios I've outlined, the GPL turns a lot of people off, and for good reason! It's a fairly restrictive license in that the cost of use is an open product. Making it known that alternative licenses are on the table mitigates that, but only if people inquire. I would think it would be toxic for Parallax to be known as a GPL company.

So then, I would do a covenant style release to get the value chain moving for all interested parties, and defer a public code release until such time as there is little risk, say after Propeller II is in the middle of it's life cycle.*

*Despite Parallax offering an extremely long life cycle, I'm defining life cycle as the period between releases of future generations of the Propeller, not the actual consumption life cycle.

Also given the above, I would hold a planning summit of some kind where these alignments of interest can be sorted out for best overall licensing terms so that everybody experiences a very solid chance to succeed and actually profit from their efforts to build that value.

Summary: Don't just open it. Not yet, and not MIT.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

potatohead
12-12-2009, 01:49 PM
One other path is to create a semi-open pool to save on legal costs and to simplify the whole process.

Create the Parallax Public License, with terms and conditions such that derivatives are restricted to some sub-class of possible derivatives, and where they cannot be made completely open, MIT style.

Again, the MIT is always on the table, but not a requirement to do "open" development for the purpose of mutually adding value to the Propeller.

That's it for me, just wanted to put the idea of there not having to be just one license release for everyone always on the table for consideration here.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

SRLM
12-12-2009, 03:07 PM
I vote for not releasing the source code for the reasons that others have put much more eloquently (namely competing releases confusing the market.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm

Clock Loop
12-12-2009, 04:11 PM
Ken Gracey (Parallax) said...
I'll be traveling to Minn - St. Paul Sunday through Monday.


Oh? Welcome to my town. Can I crawl into your suitcase and come out to parallax land? Its too cold here. Only thing I can think of on why you'd be coming to this frozen tundra is due to something Christmas related. They have elaborate Christmas light shows up here at various places... And a parallax product would be ideal for that. I'd like to shake your hand for being apart of such a great USA based company. If you meet anyone up here that needs someone familiar with the prop, bs2 and sx, I would love to help.

Plus who wouldn't want someone that can do this without a pcb and still maintain sanity:
http://forums.parallax.com/attachment.php?attachmentid=62967 LOL.

Its kind of odd you are in town the same weekend that I just started my project of teaching the youth using the propeller as an introduction to electronics, for free too. I am starting with a single young man so I can get my method down before I open it up to other young people.



I love the open source direction parallax is driving... keep it up.

heater
12-12-2009, 05:04 PM
Chris_D: "In the area of what we all do (programmers), you would think people would be smart enough to know that not all software is available for all operating systems."

That is an outrageous statement. It basically says that that people who have a desire to not use Windows are stupid.

I don't know what area you are working in but my observation is that it is precisely the programmers, as opposed to your average user, who are the ones to want to get away from Windows and Microsoft. The reasons for that seem to be very hard for "normal" people to grasp and run a lot deeper than "I like Linux better that Windows", or "Linux does not cost me anything". If it were just that trivial I would probably see it as you do.

I could now run on here with the usual of reasons: the Windows "lock in", the danger of dependence on a computing mono-culture, the restrictive licensing, the truly appalling business practices of Microsoft. The constant forced upgrade tax etc etc. The lack of control of your own computer. The impossibility of a community of computer users to collaborate in improving their OS... The technical merits or otherwise of Windows are actually quite low on the list of priorities here.

Clearly you are not in tune with those motivations yet. I recommend your reading about some of these motivations here www.gnu.org/gnu/thegnuproject.html (http://www.gnu.org/gnu/thegnuproject.html). It describes that happy playground that was computing before it was locked down and commercialized. And perhaps will show you why programmers would like to see a return to that situation.

Actually that linked story kind of describes the Propeller community here.

By the way the latest atrocity coming down the pipe from Microsoft seems to be twisting the arms the worlds hardware manufacturers to use a new exFAT for SD cards and such. With appropriate licensing such that people like Propeller heads won't be able to use it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
12-12-2009, 05:33 PM
potatohead "So, author A produced something and licensed it under GPL, forcing all derivatives to be GPL also. That's the bad viral thing nobody likes."

What ?!

The GPL may not match up with you agenda as a software author, dealer or user but I would point out that many people like it. Rather than argue in general I will present a simple case.

My humble offering to the Propeller community is an emulation of a 8080/Z80 microprocessor. I'm quite happy for anyone anywhere to use that code for fun and even for profit. I'd like it be running around as source code so that anyone who has a mind to can fix it's bugs, optimize it, extend it, adapt it to different hardware etc etc. This openness benefits me. As you may have noticed with ZiCog that is exactly what has happened. It now runs on hardware configurations I could never have dreamed of. Has been improved by numerous suggestions and actual code from many people. It has grown up beyond my wildest dreams.

Now there is one thing I don't want. I don't want someone taking all that accumulated effort of many people and selling it for a profit as binary only, perhaps embedded in some funky device that needs a Z80. Unlikely to happen I admit but there it is.

So the GPL would suit my intentions with ZiCog perfectly.

Parallax has nothing to lose by putting the Prop tool out under the GPL. Competitors won't learn anything more form it than they can learn here already.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Roy Eltham
12-12-2009, 05:34 PM
heater, I think he was just saying that people like you are familiar with the situation enough that it shouldn't surprise you when stuff only has support for Windows or only OSX and Windows. I am never surprised when Windows and/or OSX are the only supported platforms for things. I can hope for support across more platforms, but I can understand the reasons why many companies don't do it.

I am not as anti-Windows as you seem to be (probably because my livelyhood depends on it, since I work on PC games). I use it as my main OS (Windows 7 64bit), but I do use OSX (G4 Mac sitting here next to this machine) and Linux for some things as well (I also fondly remember my AmigaOS days).

---

I think the best reason for Parallax to release this source code is to allow for the community to develop more and better support for different platforms. I think this up-side far outweighs any down-side people have expressed in other posts here.

Also, I don't really see a down side to someone making SPIN work on other chips/platforms. In fact, I would prefer it, then I could use one language for more stuff. Is it really a bad thing if someone made SPIN work on an AVR or PIC or <insert other MCU here>? The way I see it the thing that is Parallax's advantage is the Propeller chip itself. It's a unique architecture (as far as I know) and if people want the best chip to run their SPIN code on, I think that will be the Propeller until the "Prop 2" comes out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

Nick Mueller
12-12-2009, 05:36 PM
Mike Green said it clear what is necessary.
For Parallax to have not more work (except for putting the code somehwere):
There is only one official version that is supported by Parallax. And that is theirs.
It is enough to release the compiler, assembler, interpreter and the uploader. The code released is "as is", no questions answered, no service, nothing. They just keep it up to date with their version.

I do not think they are giving away too much. It will only help to support different OSes and IDEs and help spread the Propeller. I only see a win-win situation.


My 2 cents!
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

Roy Eltham
12-12-2009, 05:43 PM
heater, the reason I dislike GPL is the part where anything it comes in contact with (my code added to it or using it) is forcibly GPL. Also, with my job I am forbidden to even look at GPL'd code that is in relation to anything I am working on, because it is too risky for our company to deal with it. It's quite common in the industry.

Of course, any code I write for the Propeller I will give away completely free. Fully public domain, because honestly I don't care how anyone cares to use it. If they make money from it, more power to them. This is just a hobby for me.

Also, honestly, you are the first person I have seen say that they liked GPL.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

mctrivia
12-12-2009, 05:46 PM
i see no situation where a product given away for free with no advertisments or restrictions of use should not be open source(under the right license). open source means you can take advantage of others code(if you chose to). and since your product is free with no chance of direct revenue there is no loss to you.

The biggest problem is much thought needs to be put into how to make the obex keep working. If Parallax makes a custom license that requires anyone writing an IDE using there code to comply to serten file and code format restrictions then the OBEX will keep on working. What we need to do now is think up how we can make the coding structure as diverse and flexable as possible while still allowing any compiler to compile the code correctly even if maybe not as optimized as it could be.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder. (http://forums.parallax.com/showthread.php?p=848975)

BradC
12-12-2009, 05:52 PM
mctrivia said...

The biggest problem is much thought needs to be put into how to make the obex keep working. If Parallax makes a custom license that requires anyone writing an IDE using there code to comply to serten file and code format restrictions then the OBEX will keep on working. What we need to do now is think up how we can make the coding structure as diverse and flexable as possible while still allowing any compiler to compile the code correctly even if maybe not as optimized as it could be.


A custom license is a legal nightmare. A very simple rule should apply that will make it completely unambiguous. If it does not compile with the Parallax compiler, it's not welcome in the OBEX.

Your argument on open source falls down in several places. One of note would be if I happen to use some code in one of my freely published projects that I also shared with a commercial product. In this instance, giving away the source could constitute a risk to my intellectual property.

Roy, chalk me up as someone who likes the GPL also. I actually prefer the LGPL, but either is ok. The concept of you using my code is all fine and good, but I want a license that *forces* you to give me back any improvements you make to my code. In this instance, the LGPL with the binary linking exception used by the freepascal project is nice. I use their RTL code in bst. The three portions of it I've modified/improved I've fed back to the team, but I don't have to release the source to my software. It's a nice compromise.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Nick Mueller
12-12-2009, 05:57 PM
> What we need to do now is think up how we can make the coding structure as diverse and flexable as possible while still
> allowing any compiler to compile the code correctly even if maybe not as optimized as it could be

This is simply the task of the one who made the port. Time will show, users might spot problems, the community will help to fix them. This doesn't require any kind rules.

Darwin will help here. The IDE xy has problems that aren't fixed, so people will move to a better supported one.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

mctrivia
12-12-2009, 06:13 PM
Nick Mueller the issue is mainly on how to handle compiler optimization.
i want to be able to write 1 code and use #if def like commands to customize to different platforms.

at present this would make the code not work on the ide but other compilers would understand.

if parallax could put in place something for example:


#ifdef A
//run code if macro A is defined parallax ide ignores it..
#endif
#ifpide
//parallax ide include this section
#endif



this would require parallax to make a change to there ide to at least recognize ifdef but only needs to utilize the ifpide. in this way code could be optomised but could still compile on parallax ide. Custom IDE could have a test with parallax option programmers could use to test it still works before submitting to obex.


I am not saying this is the best solution. I am saying this is the kind of things that need to be thought up and changed in the IDE before code can be released and not cause fracturing of OBEX.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder. (http://forums.parallax.com/showthread.php?p=848975)

heater
12-12-2009, 06:25 PM
Roy Eltham: "I am never surprised when Windows and/or OSX are the only supported platforms for things"

In general I am not surprised either. Saddened but not surprised. Here I'm talking things like games, media players bla bla.

BUT in the world of engineering I am very surprised when a platform specific tool is the only way to make use of a particular product.

Don't get me wrong. I am not "anti Windows" as such. I am damn annoyed at the world constantly telling me that I HAVE to buy, install, learn, use, some product that I have no interest in just so that I can do something else that I do have an interest in. Especially when it is totally unnecessary for that dependence to exist.

Simple case, I wan to use a 5 dollar Propeller chip. What you saying? I have to go out and pay for such and such an OS which has nothing to do with that chip. Go through all the hassle of installing it on my machine and disrupt everything else I do here. Oh, what's that?, I can set up dual boot or get a second machine, thanks.

Roy again "the reason I dislike GPL is the part where anything it comes in contact with (my code added to it or using it) is forcibly GPL"

If you want to use someone's code you have to pay their price. If the price is to high don't use it, write your own. It's that simple. It's quite common for software to be written using others objects, libraries, widgets whatever. You pay the money, accept the restrictions, get the licence and everyone is happy.
It's the same with GPLed code. Except the price is is not monetary.
Why do you expect to be able to leech GPLed at no cost? If the cost is to high write your own or pay some else to do so.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Roy Eltham
12-12-2009, 06:29 PM
BradC, I guess the thing for me is that if I am willing to release the source code then I am willing for it to be completely free of any restrictions. If I want restrictions then I don't release the code, simple as that (this case is really rare for me).

If I could I would release all the code I have ever written for work as well. I think the benefits of open and free sharing of code without restrictions far outweigh the possible negatives. I would love it if people could learn from the graphics engine work I have done over the years. Sure there are people that would just take it and use it for their own projects (even claiming it as their own), but for every one of them their would likely be several others that gave credit and/or released improved versions or just gave constructive feedback that would allow me to improve future code. Realistically it would take considerable effort for someone to take just my source code and produce a final product (competing or otherwise), so I'm not really worried that much about that.

Anyway, I do understand the intent of GPL (and LGPL), I just don't agree with it's method. In my experience, one tends to get a lot more positive responses from asking verses demanding.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

heater
12-12-2009, 06:36 PM
Why not keep it simple:

1) Release the Prop Tool under the GPL or BSD or such licence.
2) Give that release a different name so as to ward off support calls.
2) Yet another custom Parallax licence just adds more complication and confusion to the mix.
3) Point any support queries about the open release to the forum here :)
3) Parallax is in the business of selling Propellers here, what happens to the Prop Tool code is not important. We want you busy working on Prop II :)
4) Except, that an open tool sucks in a bigger pool of customers for the Prop, especially after it has been enhanced by the community that might grow around it.
5) Don't worry about OBEX. What stops me posting code there now that does not work with the PropTool? The Prop community here that's what. If my new object were useful but incompatible there would soon be lots of shouting about it. All it needs is a comment or check box in OBEX where people can point out "Hey won't compile with PropTool"

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Roy Eltham
12-12-2009, 06:40 PM
heater, I do not "expect to be able to leech GPLed at no cost". I full respect the licenses use by anyone releasing code. In the case that they choose to use GPL, I simply do not look at or use their code.

I don't like to think of it as leeching, nor do I wish to steal anything from anyone. I just prefer that if someone is going to release their source code in hopes of getting the most people to use it and positively contribute that they not use GPL.

Also, I sympathize with your position on products only supporting Windows. However, what about from the other side? If I make a product and have limited resources but want to reach the largest market of people then it's probably a good idea for me to support Windows. Sure, in an ideal situation, enough resources are available to support more platforms, but often times that is not the case. It's usually not a case of them "telling you that you have to buy, install, learn, use, some product that you have no interest in", but more them providing the support that they can given their resources and reaching the largest market they can in the process.

Parallax is in a position where they are willing to release source code in order to allow the community to expand the supported platforms. I think this is a great thing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

heater
12-12-2009, 07:06 PM
Roy, "If I make a product and have limited resources but want to reach the largest market of people then it's probably a good idea for me to support Windows"

Yes you are totally correct. That is why the entire worlds computing infrastructure is now held to ransom by a single corporation. A dependence on a single source is bad enough but for most of us it's a foreign single source. I just think that is an incredibly dumb situation for the world to be in.

Fortunately, thanks to people who have been thinking about this for a long time it is now possible for people like Parallax to create cross platform tools fairly easily.

One of the simplest ways to get cross platform for free is just to release your code and let the interested community take care of it.

As I say, Parallax wants to sell chips, so the IDE is just an overhead to that aim. So nothing to lose by opening it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Nick Mueller
12-12-2009, 07:18 PM
> i want to be able to write 1 code and use #if def like commands to customize to different platforms.

In my eyes, this also isn't a problem.
Just write "requires XYZ" in the description. The PropTool will fail to compile. With a bit of hand-fiddling the code, it should compile with the blessed IDE.
The good thing is: The better and more widely used IDE will win "the battle".

Looking at my cristal ball I see the following:
A few attempts to build a different IDE will be undertaken (or be continued). People see that tool-chain X is better than the PropTool (not meaning that bad) and Parallax will switch and take that IDE as blessed. You'll see, that will happen within one year. And its an advantage for both sides.
I see the Parallax people as being quite relaxed and open-minded about that subject. Give them the time to assimilate to that idea and I bet they will like it. As a lot of others will.

Of course there will be branches of that tool-chain. Like compilers for OS$whatever. But the mainstream IDE for Win/*NIX/Mac will be a single one that is completely open sourced and has a blessed branch at Parallax's site.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

potatohead
12-12-2009, 07:33 PM
Heater, I need to be clear. You can go google me to vet this. Just PM me, and I'll hook you up with the details. Suffice it to say, you will find numerous writings of mine, some prominent, articulating the ideology of open code and why it matters.

I love the GPL, and I love it for the growing and always open body of code we have today. I understand the use value of that, I understand the political value of that.

Where pure matters of software are concerned, I have few hesitations using GPL software, and have written and contributed GPL software to that body of code. I did so gladly, moved by the very significant use value proposition I found in that body of code; namely, one gets more out than they put in!

This is not a software only matter. Hardware is a part of the mix. That makes things different, thus the "viral part nobody likes" A large fraction of products are closed because they are required to be closed at this time. As open grows, that will change, and when it does, less of this will be a worry. Now is simply not that time, that's all.

What I wrote above is from the perspective of basically, "If I were Parallax". And if I were Parallax, in this market, with these competitors, having my stuff made off-shore, I would absolutely give the risk inherent in that as much consideration as I would users. I don't think any of us would do anything less.

Simply put, there are business realities and families to be fed that warrant some caution as to when to open that code.

Assuming it's actually when, I would prefer the GPL, as all derivatives would then be open. I also prefer the different release, to protect those unable to make use of GPL code. Finally, I would do it, because commercial licenses can be issued right along side that GPL.

If Parallax wants to sell the most chips, they would be wise to have a closed path for those that need closed. Political realities dictate this. Ironically, a GPL release is the strongest one for this, because of the strength of the license, and the clear boundary between open and closed.

From their point of view, there are two markets. The growing open one, and a closed one, and they manage the closed one much like they do now, while the open one does what open ones do best!

Releasing under MIT, for example, allows somebody else to also serve the closed market, and that's a control issue I personally would be wary of, again given this industry and the nature of many players in it.

Before doing either, a limited release, under a valid and viable limited disclosure and redistribution contract is something I would do first, if nothing else, but to reward those who are able and willing to innovate now. Let that occur and build a more solid base before opening up. Should it not go well, no open release has occurred.

Should an open release occur, those who agreed to terms earlier could also then do open things with no worries, just like anyone else.

My reasons for this are:

1. Limit risk and maximize value early on. There is some really great potential that can occur now, without a wide open release, and that does not prohibit said release. This is a free card, in poker terms.

2. It is very important that Parallax remain the authority here, as it is their holistic design that is part of their value add to the product. Other efforts to expand on that are good, welcome, and I would argue necessary, but do not define the product in a primary way. This is a key business differentiator that needs to be protected. A nice chuck of what I do surrounds these kinds of issues, and I've seen that go badly before.

It is extremely important to preserve differentiators and leverage them to a high degree to remain sustainable, period.

3. If there is an open release, I oppose the MIT, because then the line between open and closed will be blurred, and that will empower competitors, who may or may not hold to Parallax standards and this has the potential to either empower a nefarious competitor, or dilute the brand differentiators as noted above.

GPL is actually best in that Parallax remains the authority, and the arbitrator between what is open and what is closed as their business needs demand over the longer term. Open adds the most value when it is open always, adding to the body of other open code, making that use value proposition stronger for all involved. In this way, open is a solid competetor, and that is necessary in this near mono-culture we live in.

I hope I'm clear enough on that.

Guys, I value open as much as anyone here. I also am acutely aware of the business realities for many in this industry and in the one I serve for my day job. Growing open is always good. Existing on only open is difficult. Closed is necessary, while open grows. The most potent tool for this is the GPL, not MIT or BSD style license, as both of those allow competing closed derivatives which dilute the authority of the originator who publishes under them. I believe that would be foolish for Parallax at this stage of the technology development cycle as a whole. (Prop, I, II, III and surrounding products)

Edit: Having better established the Propeller, the need for being the primary authority will diminish as a function of the ecosystem surrounding the chip grows. That's also my primary reason for risk limitation. Right now, I don't see that ecosystem as authoritative enough to check the cost of risk, it's that simple. A release under contract would actually grow that eco-system, keep risk low, and reward early adopters. That is the only reason for suggesting it, and I concur with Mike on this point, assuming he was thinking along similar lines.

From a business point of view, risk flat out equals dollars over time. The means and methods I outlined are structured to incrementally maximize potential mutual value propositions (prop + either product, or code product = more value than just prop + Parallax IDE), while limiting risk growth.

From an ideological point of view, I say "Hell yes! Open the thing, as once it's open, it's always open, and that is good".

I take the business perspective here because ideologically I would be gratified by a seriously open release of these things. It would be a shame to have made that statement, enjoyed the fruits of it, only to see it all die on the vine with either no future propellers, or significantly changed ones to recover from an unanticipated situation that required drastic means to recover from. When I am 20 years older, I hope to be building Propeller stuff for people, doing it on open tools, competing with and beating out closed alternatives and life would be good.

Getting there means managing risk, at least that's what I believe and what my life experience has shown me.

Finally, I take that perspective because not everyone in the discussion is, and that's just healthy, and because I have been treated so well, welcomed and encouraged on a level I find amazing. I sit here at my desk with these electronics I left so many years ago, using some tools shipped to me because I expressed interest, nothing more. I am compelled to give back my thoughts as best I can, giving that "family" the greatest consideration I can, and considering the business element must be a part of that. There is Parallax, who has been excellent and a mentor to me, and others a part of this community who have done the same. That has stellar, off the chart use value. Consideration due is consideration given, maybe that's how I can put it best.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/12/2009 12:18:51 PM GMT

evanh
12-12-2009, 08:20 PM
Roy Eltham said...
Anyway, I do understand the intent of GPL (and LGPL), I just don't agree with it's method. In my experience, one tends to get a lot more positive responses from asking verses demanding.

GPL is a license to combat stealing as is every other license out there. All legal documents are effectively a demand backed by state law and enforcement.

Even the MIT License still demands credit be given. So, it defines stealing as not giving credit to the author.

Asking has no impact on those that are doing the stealing. And when they then use the stolen code for monopolistic purposes again those who are playing by the rules. Wouldn't that suck?

The GPL has a few benefits for those companies investing considerable resources into a GPL'd product. It is designed as a commercial level license. Treat it as such when comparing.

evanh
12-12-2009, 08:25 PM
Go easy on the "viral" insinuations too. As an example, any non-disclosure clause is also viral. You could say the viral part of the GPL is a compulsory disclosure clause. :P

potatohead
12-12-2009, 08:36 PM
Sorry to pick a nit, but it's infringement, not theft. This is not to say it's not as bad, maybe worse. Don't get me wrong there. It feels like theft too. Been there in the past, done that.

I only make this point because a significant contributor to the sorry state of our IP environment today is the sometimes contrived improper use of the worth theft in the discussion. This is often done to capitalize on the strong and ubiquitous negative connotation associated with theft, and out of simple ignorance, or to leverage simple ignorance in legislators of all people.

This can be mitigated by greater use of the correct term, infringement, and doing so will then better realize the elements of the debate as a whole, yielding us laws rendered to actually work for us in a way all can live with, instead of kludges we all struggle with.

The reality with these things is all about those who consume and distribute while not being entitled to do so. Nothing was stolen, as both those with entitlement, or who hold rights, still retain their rights and entitlements; therefore, no material element of theft exists, meaning a case for theft cannot be made. We have the word infringement for these matters, please use it.

I truly believe this matters in the end. Thanks! :)

Carry on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/12/2009 12:46:58 PM GMT

potatohead
12-12-2009, 08:37 PM
Agreed on "viral". This element of the license is a good thing in the end, but must be discussed. If I did more harm than good with "viral", I'm sorry and will always work to get better about it.

I think I've said my bit here too. Really I saw some elements not part of the discussion. They are now, and I'll sit back and watch how it all goes in the end.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/12/2009 12:45:19 PM GMT

evanh
12-12-2009, 08:46 PM
potatohead said...
Ironically, a GPL release is the strongest one for this, because of the strength of the license, and the clear boundary between open and closed.

From their point of view, there are two markets. The growing open one, and a closed one, and they manage the closed one much like they do now, while the open one does what open ones do best!

Quote for emphasis. A well written posting all round.

evanh
12-12-2009, 08:50 PM
potatohead said...
Sorry to pick a nit, but it's infringement, not theft.

Cool, doing some insinuating myself. ;)

heater
12-12-2009, 09:14 PM
Potatohead: Looks like we are basically like minded on this topic:)

I can understand the need for closed software. It's a way to make money, write a program, sell it, profit. Open would kill that possibility instantly. If that is your business model then go for it. It will work, until some else creates a better program for cheaper (Word over WordPerfect say) or until the users community comes up with hits own solution.

My point is that Parallax is not in that business. In the case of the Prop selling chips is the business. I can't see how GPL'ing the IDE can hurt that business in any way.

They don't lose money when I use BST instead of the Prop Tool. They even gain because I buy chips that I may not have done if BST were not available.

They don't give away any Prop secrets to their competitors by opening the IDE.

What's the problem?

Well, you did mention that the Propeller product is not just the Propeller but the "holistic" value of the Propeller chip, the IDE, the OBEX, the support system, the forum (yes us), the documentation, the demo boards etc etc.

This is a very good point. The Prop product is not "just another chip". However again I don't see the problem with opening the IDE. Give the open release a really different name to distinguish it from the supported version and avoid trade mark issues. A really stupid name as is popular nowadays ("Iceweasel" for a web browser, jees).

That open IDE will take on a life of it's own out in the wild. Or not. What difference does it make? Someone might start hacking on it, others may join in. Then we have a divergent, perhaps incompatible tool. So what? It subtracts nothing from that "holistic" Propeller product. But it will encourage others to buy more Props.

I like it. Why? I want the Prop and it's future incarnations to be around for a long time to come. This seems an excellent way to allow it to spread and grow.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Roy Eltham
12-13-2009, 01:30 AM
This is the last thing I'll say about GPL. If it's released GPL, then I won't even look at it, let alone contribute to any tools using it, and I think that I could contribute positively. That is how strongly I feel the GPL is the wrong route to take to be open. I am pretty certain I am not alone in my dislike of GPL.
---

I am also, pretty certain that you guys are not thinking about all of the possible uses of this code. Uses that would quite likely be blocked or at least hindered by the GPL. Uses that could benefit Parallax where it counts, the sale of significant amounts of their hardware. Uses that are not even anything like an IDE or traditional compiler.

The PropTool is free, someone creating a competiting tool that they charge for just doesn't matter. Who's going to use that now when the free version is the one made by Parallax and has been out longer?

The only situation I see where releasing this code can hurt Parallax is if someone uses it to make some form of clone Propeller hardware, and realistically someone willing to do that won't really care about any license you throw on this source.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

hippy
12-13-2009, 02:42 AM
I'm with Roy and others; no GPL though Parallax haven't suggested that it would be GPL.

I personally hate GPL, I see it as a viral cancer, politically motivated and unreasonably restrictive. I don't see a problem with fully unrestricted licensing and others taking that, commercialising and profiting from it; it's not like access to the original is removed. Far better IMO that something useful is done with my code than it never being taken further for lack of resources or interest.

And let's be honest; very few will find the Parallax source code release really useful, and probably even less will set up in commercial competition ( I'd guess zero ). Bottom line is that if it doesn't adversely impact the existing business no harm is done. I believe Parallax are more than capable of making such a risk assessment.

Ken Gracey
12-13-2009, 04:13 AM
Many good points have been made and all of you are considerate to be concerned about the long-term welfare of your business, Parallax. <= how's that for open-source? We will have to become a 501(c)(3) non-profit when we're done giving everything away.

All fun aside, one motivating fear against an open-source release is that we could enable a competitor to develop a hardware product from our code. What if a competitor used our material to make their own "Propeller", then pursuing us under patent infringement over their new "multicore" patents? That's a dirty thing to do and probably not very likely.

On the other hand, establishing prior art is a strong reason to release since our legal policy is to defend ourselves and protect what we've engineered.

Whatever we do today should not cause us need to work more closely with lawyers in the future. While mentioning lawyers, a company with bad intentions or patent sharks should know that we're ready to fight for what's ours, just in case they're reading. . .we all know that a "well-trained" Silicon Valley legal team could bring Parallax or similar company to its knees paying legal fees. But we'll die on our feet before we live on our knees. I really shouldn't be thinking out loud on these forums.

I'm think that the IP protection rage with lawyers is waning a bit in the USA. It's bad for our economy, innovation and customers. Who really wants to base on product on intellectual property that was made available with an exclusion for commercial uses anyway? Bad guys do, probably in other countries. There's no stopping them, but there's also no need to help them.

Carry on, please, freely.

Ken Gracey
Parallax Inc.

Post Edited (Ken Gracey (Parallax)) : 12/12/2009 8:33:57 PM GMT

Clock Loop
12-13-2009, 04:32 AM
Ken Gracey (Parallax) said...
What if a competitor used our material to make their own "Propeller", then pursuing us under patent infringement over their new "multicore" patents?


The army of parallaxians here would take them down.
I have never used any product that had a following like parallax does.

heater
12-13-2009, 04:37 AM
Ken: "What if a competitor used our material to make their own "Propeller"

A valid concern.

I think there is enough published material on the Prop that it is quite possible for anyone keen enough to create a Propeller clone already. After all by necessity the instruction set, op-codes, memory capacity, timing info are published so that your users can get on with the device.

Copyright law does not stop anyone developing their own implementation. You don't have patents. Only trade mark law stops them calling it a Propeller.

There is one big hindrance to the cloning process and that is the Spin interpreter in the Props ROM. Cloning that is a violation of copyright and writing a clean room version might be very hard.

The fonts and tables in the ROM are probably protected by copyright.

Given that I would not worry about clones.

Is there really any information about the operation of the Propeller that a clone maker would need hidden in the source code of the Propeller Tool? Some how I think not.

By the way, it just occurred to me that perhaps Chips idea of putting a self hosting IDE in the Prop II ROMS is a damn good way of obtaining legal protection against cloners. It would clearly be copyrightable.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mctrivia
12-13-2009, 04:38 AM
Ken Gracey said...
All fun aside, one motivating fear against an open-source release is that we could enable a competitor to develop a hardware product from our code.


I would not worry about someone using your code to make a hardware platform. There is already enough information about the propellers inner workings publicaly available that it would be fairly easy to duplicate the propeller. The only things stopping anyone from doing this are:

1) Startup cost to get a custom silicon chip made is very high.
2) The cost of the prop chips is very low
3) Reverse engineering a product is illegal

With these 3 things the reward for duplicating the prop is not worth the legal and financial risks. If someone wants to compete they are far better off to design from scratch a processer with similar layout but more memmory, more io, and more cogs. XMOS is probaby the closest thing there is to a competitor you have. It is faster, has more memmory, and more threads. But it is also more expensive, more complicated, uses more power, and has lass support. I will chose yours over any competitors so long as your company keeps its moto of "make it right the first time and support the comunity" and you do not fall to far behind in the MIPs and IO category. Prop II may be a year behind its time already but comunity, price, and perfection will make it a keeper.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder. (http://forums.parallax.com/showthread.php?p=848975)

mctrivia
12-13-2009, 04:44 AM
Clock Loop said...
The army of parallaxians here would take them down.
I have never used any product that had a following like parallax does.


Quiet literally. I see an army of prop2 ICs all over the globe in parallel attacking the sights web sight. If my web server alone has the power to shut down must web sites until there firewall blocks me what would they do from an orchestrated attack of 10s of thousands of propellers all attacking in such a way as not to trigger firewall block outs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board now in. $21.99 has backlight driver and touch sensitive decoder. (http://forums.parallax.com/showthread.php?p=848975)

grahamreitz
12-13-2009, 04:50 AM
Thanks Ken!

This is an excellent discussion.

Consider:

1) What are Parallax's core competencies?

I suspect it's the hardware and not so much the software. The fact that some of the software was written in x86 assembly is brutal and unusual in tool development on a modern OS. It's also quite an achievement by today's standards. There also seems to be a culture at Parallax that is anti-software, unless it's yours. Yea, Windows does that to the educated, informed, and burned.

2) Share only what you need to.

As an interested tool developer it would be good to know all of the information required to write or port a compiler/linker/assembler to the Propeller platform without having to reverse engineer anything. It's not necessary to open source your code unless it provides algorithms or methods that are difficult to document or understand. Although, having source code is a good reference to start from.

It's fairly clear that there is a contingent of Propellerheads (myself included) that have no interest or desire to use or learn Spin. It's a great method to introduce newcomers to software development but for serious work it's less desirable due to its proprietary nature.

3) Multicore is the future

It's only a matter of time before your competitors start implementing them on their micros. Do it better and with more flexibility than they will offer.

This flexibility is already implicit in the Propeller's hardware design. Go the rest of the way to make it as easy as possible for engineers to port development tools to your hardware platform or write their own.

Respectfully,
graham

James Long
12-13-2009, 04:52 AM
Ken Gracey (Parallax) said...
Many good points have been made and all of you are considerate to be concerned about the long-term welfare of your business, Parallax. <= how's that for open-source? We will have to become a 501(c)(3) non-profit when we're done giving everything away.

All fun aside, one motivating fear against an open-source release is that we could enable a competitor to develop a hardware product from our code. What if a competitor used our material to make their own "Propeller", then pursuing us under patent infringement over their new "multicore" patents? That's a dirty thing to do and probably not very likely.

On the other hand, establishing prior art is a strong reason to release since our legal policy is to defend ourselves and protect what we've engineered.

Whatever we do today should not cause us need to work more closely with lawyers in the future. While mentioning lawyers, a company with bad intentions or patent sharks should know that we're ready to fight for what's ours, just in case they're reading. . .we all know that a "well-trained" Silicon Valley legal team could bring Parallax or similar company to its knees paying legal fees. But we'll die on our feet before we live on our knees. I really shouldn't be thinking out loud on these forums.

I'm actually starting to think that the IP protection rage with lawyers is actually waning a bit in our USA society. It's bad for our economy, innovation and customers. Who really wants to base on product on intellectual property that was made available with an exclusion for commercial uses anyway? Bad guys do, probably in other countries. There's no stopping them, but there's also no need to help them.

Carry on, please, freely.

Ken Gracey
Parallax Inc.


Ken,

Although you do make extremely focused and valid points, I do not think that is the main issue for me with open-source.

So far the Propeller community has worked well to define the Propeller with a multitude of functionality. Most of this based in a IDE which is tied to Windows. I am discouraged the IDE doesn't function on Mac's, even though I do not use or own one.

I am scared the open-source could possibly spread the "peanut butter" too thin. For example, if you end up with a vast array of IDE's (possible but not likely), where will the center focus group be? Sure many will still be here churning out great Objects from the Standard IDE, but many others may be diluting the effort with IDE's which are not inter-compatible.

If Parallax was the size of Microchip, the issue would be moot. But the Propellers success, unfortunately, is partially due to the restrictive nature of the programming (if it hadn't been, I would have elected to use a language that I knew). If 50% of the people making objects had been using a non-compatible IDE, then only 50% of the OBEX would be useful to each user(not in real terms, just an example).

I do understand that open-source adds some possibility to expand the success of the Propeller, but I also feel it may detract from the future success of the group effort (which is the Propeller's greatest asset, in my opinion).

I'm not sure the Propeller is mature enough for "open-source" status.

I personally think, it's not a bad idea, the timing is just not right.

This is only my opinion,

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services (http://www.lil-brother.com)

Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits (http://www.savagecircuits.com). Learn to build your own Gizmos!

potatohead
12-13-2009, 05:21 AM
@heater: Yes, absolutely it would, and that is one of the things I like about self-hosting, regarding this discussion.

@hippy: Understood, and agreed. My own experience here with the OBEX and sharing code to better ourselves is one where the GPL is toxic. I must highlight, given the context of my earlier contribution, the use value of the pool of GPL code and MIT, BSD, and even plain old Public Domain code is all high, and all share the property of you get more out than you put in, or it's at least possible to get more out than you put in.

For me then, it's the intent of the pool or body of code in question. With the OBEX, I prefer the MIT because the intent is to empower people to build things they either find useful, or profitable. Nobody cares if closed derivatives are produced from the OBEX, as that is the intent. That's all good, and I see clearly where the GPL is toxic. On the other hand, that pool isn't something necessary either. One can take it or leave it and be uninhibited either way, thus the threat of closed derivatives is an empty one, and it all just works.

Those proponents of the GPL, who do not want the threat of closed to be at issue, realize that necessary tech is a prime target of closed, and resent how it is so often used. Secondly, if open is to grow, it must do so without also feeding the closed pools of code, meaning the cost of open is to deny closed, and that's why GPL surrounds necessary tech. That pool of code is always open, and will grow unless every user denies that use value. This is as necessary as the tech is.

The code we are discussing here isn't strictly necessary, meaning there is a strong case for MIT. For us users, particularly those active here, the intentions are clear. People just want to add value and build stuff. That may or may not always be true, and with that comes risk for Parallax. A GPL release would marginalize that risk, and be strong should that risk come to pass, leaving Parallax in greater control over the product definition, while not inhibiting truly open efforts.

If somebody can't do that, for whatever reason, a non GPL license can be issued to that person, and that was the point of my post above as well. Being the originator of core enabling technology, Parallax is in a position where such management is necessary, if they are to manage risk, that is all.

A MIT release is essentially a blanket statement that Parallax doesn't care who does what with that code, as once released, that is exactly the result, whether they like it or not. The difference between that and GPL is the profit motive, and the need to be open. Those two check most reasons why somebody with nefarious intent would go down this road in the first place, where the MIT does not.

The burden then is sorting out whether or not Parallax could say that with impunity. Can they? Really?

I'm not convinced they can right now, at this time, thus my support for the GPL... Edit: or no release at this time, or a release under binding contract, where the well aligned interests are known to strengthen both parties as a whole.

@Ken: That's pretty funny actually!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/12/2009 10:55:13 PM GMT

Phil Pilgrim (PhiPi)
12-13-2009, 05:40 AM
James Long said...
...where will the center focus group be? ... If 50% of the people making objects had been using a non-compatible IDE, then only 50% of the OBEX would be useful to each user.

This is the point I tried to make earlier. The OBEX has to be the focus, and anything submitted to it has to be compatible with Parallax's official dev tools to avoid splintering. Someone may have to enforce this compatibility, too, as voluntary compliance could be an inadequate safeguard.
___

It's a tiny bit ironic that Parallax now finds itself in this potential position. Year's ago, they were on the other side of the fence, when they created their own assembler for Microchip's PIC processor and completely re-invented the mnemonics (thank goodness: the official mnemonics are hideous). As a consequence, programs written using the Parallax mnemonics, although easier to read, were incompatible with Microchip's own dev tools, and Microchip seemed to hold the new mnemonics in disdain (as experienced by my early tech support experiences with them). Since then, the mnemonics live on in Tech Tools' assembler, which was purchased from Parallax; and Microchip seems, more recently, to be granting them grudging acceptance. But still, any programs appearing in Microchip's code library and app notes use their own mnemonics, and that's the way it should be.

-Phil

James Long
12-13-2009, 05:50 AM
Phil Pilgrim (PhiPi) said...
This is the point I tried to make earlier. The OBEX has to be the focus, and anything submitted to it has to be compatible with Parallax's official dev tools to avoid splintering. Someone may have to enforce this compatibility, too, as voluntary compliance could be an inadequate safeguard.
___

It's a tiny bit ironic....


Phil,

I did get your point, and was definitely agreeing with you.

I will keep my fingers crossed, and hope to see an outcome that sides with success.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services (http://www.lil-brother.com)

Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits (http://www.savagecircuits.com). Learn to build your own Gizmos!

Luis Digital
12-13-2009, 06:18 AM
What are you afraid of?

Created languages incompatible with spin? That already exists (Basic, C, etc.).
Indeed, many are happy with the different versions of C, even have an official section on OBEX.

Other compilers / IDEs? That already exists.

Create a multi-core microcontroller? There existed before Propeller. And I see no reason to be afraid at this point, because the information was released long ago.

Gentlemen (and ladies?), new information just may help create or improve existing compilers.

SRLM
12-13-2009, 06:21 AM
ClockLoop said...
The army of parallaxians here would take them down.
I have never used any product that had a following like parallax does.


Sparkfun is going through a similar situation. As it appears now the "army of Sparktonians" seems to be ineffective. I sent an email on their behalf, but didn't get a reply...

www.sparkfun.com/commerce/news.php?id=300 (http://www.sparkfun.com/commerce/news.php?id=300)



Sparkfun Followup News post said...

First off, we want to give a hearty "thank you" to all of you for your impressive display of support in the previous news post. Just as we are continually amazed by all the cool projects you guys/gals put together, we are also impressed by the amazing number of comments and the large amount of email support regarding the "cease and desist" letter we received.

We really do appreciate the support you have all offered - it's amazing to have such a committed community base and we are honored to have you on our side. If you'd like to help us, please email sparcinfo@sparc.org explaining the reasons why you believe SparkFun and SPARC International would not be confused. Please keep in mind there are people involved on both sides, and threatening emails will not help our cause.

To give you an update: we are at the beginning of what we assume will be a long legal battle. It is unfortunate, but this is why we have experienced legal counsel on staff. We are optimistic, but we are preparing for multiple outcomes. Our 'people' have talked to their 'people' and we just keeping doing what we do best - building, tinkering, and having fun. Nothing will change overnight and we will keep our customers and fans up-to-date as we hear it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm

cgracey
12-13-2009, 06:42 AM
Lots of discussion here! Most of you know way more than we do about the pitfalls of various "open" schemes.

There is really no secret ingredient to making a new Propeller IDE. It seems to me that the Propeller Tool GUI is pretty understandable, based on what you see it do. The internal compiler, written in '386 assembly, is not so blatant in its function, but Michael Parks has made a Spin version of it called Sphinx, which I think would provide a better starting path for alternate compiler development, as it's more readily understandable.

I think the main effect that releasing the code to the Propeller Tool might have is to give people an initial sense of possibility. In the end, they would probably have to learn HOW it works, down to the bottom level, in order to make anything meaningful from it. I see this as mainly just a confidence catalyst. Might as well start from your OS of choice and study the behavior of Sphinx.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

James Long
12-13-2009, 06:59 AM
Luis Digital said...
What are you afraid of?

Created languages incompatible with spin? That already exists (Basic, C, etc.).
Indeed, many are happy with the different versions of C, even have an official section on OBEX.

Other compilers / IDEs? That already exists.

Create a multi-core microcontroller? There existed before Propeller. And I see no reason to be afraid at this point, because the information was released long ago.

Gentlemen (and ladies?), new information just may help create or improve existing compilers.


But those all comply with a set format (their own, but still a set format of a singular nature). What if someone else does a C compiler that doesn't comply with the existing one. Then you have two versions of language that do not correspond to each other. That causes confusion and frustration. Then you will have multitudes of objects for the same processor which can not be mixed to complete a task.

This not about different compilers, this is about conformity in each system.

For example, how many different basic compilers does the PIC have? How many share a common basis for programming? Not many (if any). That is for a company which produces millions (probably billions) of chips per year. Parallax doesn't have that kind of large production, and needs the "group" effort to facilitate the OBEX.

If the "sauce" is diluted too much, it's not going to be very palatable, and many people will loose interest do to lack of support in their particular flavor of programming.

The perfect example here is Parallax themselves. It is the support of "their flavor" which put them in business. The education, continuing support, and relentlessness of shoving help, down customers throats, is what makes them different than any other micro-controller company (meant to be funny, not offensive).

We are not talking about the uber active people like Bean or Hanno who are creating different programming languages/methods. We are talking about the possibility of multitudes of IDEs which may work on the PC/Mac, and not share any similarities with any other IDE.

I can list at least 10 different languages (basic in nature) for the PIC line. None of which are real good. Limited support at best. Sure it helps sell chips, but how does it help the end user? Another programming language that you must figure out on your own, or search for possible help to get it working. Hours upon hours on Google to attempt to find the answer you need. Not my idea of a great IDE/compiler. More diluted sauce. I know this, it is what made me a Parallax customer!

I may be wrong. The open-source may drive the unhappy IDE person to the original IDE, and they will become another Mike Green (we could only hope), Hanno, or Rockicki.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services (http://www.lil-brother.com)

Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits (http://www.savagecircuits.com). Learn to build your own Gizmos!

Phil Pilgrim (PhiPi)
12-13-2009, 07:59 AM
Compatibility is one of the reasons I've been pushing hard for preprocessor hooks in the Parallax IDE. A preprocessor can expand and manipulate the language in many interesting ways. But its output is still plain vanilla Spin, since that's what the compiler accepts. And plain vanilla Spin is what has to be the lingua franca of the OBEX.

In this light, one possible alternative to completely open-sourcing the IDE would be to produce freeware versions of the compiler that run from the command line on the three major Intel-based platforms: Windows (done, i.e. Propellent), Linux, and OS/X. Since the compiler is written in i386 assembly, this should be as simple as adding OS-specific wrappers to it. If the compiler were widely available on these platforms, programmers would be encouraged to use it, in lieu of rolling their own and, possibly, introducing language inconsistencies.

-Phil

Luis Digital
12-13-2009, 08:20 AM
James Long,

With current information it is possible to create compilers compatible / incompatible.

As Chip said:
"There is really no secret ingredient to making a new Propeller IDE."

Oldbitcollector (Jeff)
12-13-2009, 08:38 AM
This whole thread (and idea) was born out of comments on Adafruit's blog and soon after the PropScope thread
on Parallax being a "closed" company in regard to Open Source.

Personally, I don't see where releasing the IDE will make much of a difference as a whole. As Chip and others
have said, enough material has been released to allow alternate compilers already. What it *might* do is change
a little of the perception. (maybe).

I'm still extremely confused when looking at the other "Open Source" microcontroller why everyone
goes crazy over it? It does much less than the Propeller. Every other day I see some RSS feed in my
newsreader in which someone makes it do some that we did on the Prop a year or more ago and now it's a big deal.

I don't see Atmel releasing more data on that chip than Parallax has released on theirs. What's the difference?

The last thing I want to see is Parallax releasing information which allows Propeller clones to be created,
and quite frankly releasing the Propeller Tool appears to be a waste of time and resources I'd rather
see committed to improving the current product or re-tasked to finishing the Propeller II or some other
forward moving project.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

evanh
12-13-2009, 09:18 AM
hippy said...
I personally hate GPL, I see it as a viral cancer, politically motivated and unreasonably restrictive. I don't see a problem with fully unrestricted licensing and others taking that, commercialising and profiting from it; it's not like access to the original is removed. Far better IMO that something useful is done with my code than it never being taken further for lack of resources or interest

Again, you surprise me Hippy. Where is the politics? Requiring disclosure doesn't stop commercialising a product.

As has been pointed out many times over, a commercial entity wanting to use a closed edition can still ask for a special license for their purposes. So, GPL allows the author to see who is wanting what at the very lease. This is useful if the author is operating commercially.

That's just sensible business imho.

heater
12-13-2009, 09:26 AM
OBC said...
The last thing I want to see is Parallax releasing information which allows Propeller clones to be created, and quite frankly releasing the Propeller Tool appears to be a waste of time and resources I'd rather see committed to improving the current product or e-tasked to finishing the Propeller II or some other forward moving project.



I agree.

To be frank.

1) The Prop Tool IDE source is not of much use or interest. Lets face it, the world is full of open source IDE's now, Eclipse, KDevelop, etc. A lot of serious coders are quite happy with Emacs and Vi still. It's just another editor.

2) The Prop Tool Spin compiler is not much use. Of interest as a kind of ultimate reference for Spin maybe. Which it should not be if the language is defined properly. It's x86 assembler so it's a non-portable dead end. We have at least 3 third party Spin compilers now so obviously that x86 asm code is not required.

3) Purely selfishly on my part, I'd rather you got on with some more of your brilliantly productive work.

So, after much consideration, I'm now with OBC. Forget this open source idea and use Parallax's resources for getting the Prop II out and whatever other brilliant product ideas you have up your sleeves, I'm feel sure you have many :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
12-13-2009, 09:48 AM
Hippy, please can you explain to me what is the political motivation behind the GPL? I have heard this idea many times but have never understood what it meant.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC
12-13-2009, 09:48 AM
heater said...

2) The Prop Tool Spin compiler is not much use. Of interest as a kind of ultimate reference for Spin maybe. Which it should not be if the language is defined properly. It's x86 assembler so it's a non-portable dead end. We have at least 3 third party Spin compilers now so obviously that x86 asm code is not required.


I speak only for myself here, but it's of interest to verify some of the speculation and guesswork I've put into the bstc compiler about how I *think* the Parallax compiler works based on observing the generated bytecode.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

evanh
12-13-2009, 09:54 AM
Oldbitcollector said...
This whole thread (and idea) was born out of comments on Adafruit's blog and soon after the PropScope thread
on Parallax being a "closed" company in regard to Open Source.

Well, that is prolly some politics. But it's a separate issue from what license to use for open sourcing.

heater
12-13-2009, 10:21 AM
BradC: Thinking about, what you have done is quite weird isn't it?

Surely most compilers are written to conform to some language standard as input without there also being the requirement to produce some uniquely correct code sequence as output.

I mean, generally two C (say) compilers for the same processor will not produce the same code sequence as output.

So what you have done is above and beyond the call of duty.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Beanie2k
12-13-2009, 10:22 AM
A view from a different perch:

I have the PropRPM, which has a serial port for programming. This means that for one PC, I have to use a USB to Serial adapter. Version 1.06 of the Proptool worked fine. I upgraded to V 1.1 and it broke. It could find the Prop OK, but couldn't download a program. What to do? Call Parallax? Well, unless they had the exact same converter I had, there would be no way they could debug. Result: I had to go back to V 1.06. Compare this to two other cases.

1: Linux ver. 1.x (I forget the number) worked fine on an ancient 60 MHz Pentium (complete with FDIV bug) and an equally ancient proprietary CD-ROM drive which ran off the sound card. Upgraded to ver. 1.(x+1) and the CD-ROM quit working. Looking at the driver source, I found they had turned off the port autoconfig, and the default values were wrong. Putting in the correct values and recompiling on the old version solved the problem.

2: An open source binary file viewer/editor named Biew. Ran well on one PC, but had major video problems on another. Downloaded the source and set about debugging. Turns out the author assumed that the video card preserved register values across two BIOS calls. Wrong. Added a couple lines of code to properly restuff the registers and voila! It worked perfectly.

If I had the source to v. 1.1 of the Proptool, I might have been able to get it to work with the USB-Serial converter.

BradC
12-13-2009, 11:19 AM
Beanie2k said...

If I had the source to v. 1.1 of the Proptool, I might have been able to get it to work with the USB-Serial converter.


Except that not having access to the commercial components Parallax has used in building the IDE, you would not have been able to build it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Cluso99
12-13-2009, 11:56 AM
I have thought long about my reply...

What are some of the possibilities...

A lot more products being created for the prop because the code will provide the bits necessary for faster development and for additions where there are shortcomings.
Brad & Michael would not have had to spend (waste)·so much time testing their compilers to be exactly object compatible. What other features could we have now??? Brad's runs on windoze, *nix and mac. Both these compilers have extensions (#ifdef). As heater has said, we could not have come so far with ZiCog and the various hardware platforms without this. Hanno could add other features to his commercial products. Compiling code is one possibility. I suspect Hanno may already have access and this is a good thing. Better commercial products. Other languages can be written more easily - PropBasic, etc. Certainly easier for other languages if you have access to the compiler code. Maybe spin on competing hardware (micro)? Exposes spin to perhaps become a mainstream language? Parallax can concentrate on other things, namely Prop II http://forums.parallax.com/images/smilies/tongue.gif
What is required...
OBEX: A new section for non-PropTool code. Why? So that we can use the extensions (#ifdef) without confusing the beginners. We already have a 'C' section and they cannot be compiled with PropTool!

I like MIT and I suspect so do Chip and Ken. I think GPL has too many restrictions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)
· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Phil Pilgrim (PhiPi)
12-13-2009, 12:12 PM
heater said...
2) The Prop Tool Spin compiler is not much use. ... It's x86 assembler so it's a non-portable dead end.

That statement puzzles me. 99% of the hardware that users run programs on is Intel x86-compatible, whether it be under Windows, Linux, OS/X, or whatever. Unless Chip is making a lot of calls to the Window API, the compiler (basically just a file reader/writer and text processor) ought to be pretty much OS-agnostic and, thus, easy to port to another OS. I would much rather see this happen, as a common, compatible kernel for the efforts of others, than to see this core piece of software reinvented many times over, with unkowable consequences.

-Phil

Phil Pilgrim (PhiPi)
12-13-2009, 12:19 PM
Cluso99 said...
What is required... OBEX: A new section for non-PropTool code. Why? So that we can use the extensions (#ifdef) without confusing the beginners. We already have a 'C' section and they cannot be compiled with PropTool!

I strongly disagree. That's a slippery slope which will lead, ultimately, to the fragmentation of software development for the Prop, with a jumble of incompatible objects. Anything that's written using conditional compilation, macros, or other preprocessing can be translated into plain vanilla Spin, which (aside from C, perhaps) must remain the common (and only) language for the OBEX. I would rather see Chip and Jeff add support for these features direclty, so that programs that use them can be included. Beyond that, though, it's not in Parallax's interest to have the Tower of Babble parked in their OBEX server.

-Phil

Cluso99
12-13-2009, 12:28 PM
Phil: Parallax have stated they do not intend to add features to the PropTool.

The #ifdef has become fundamental to code I am writing. (I haven't put anything into the OBEX - note to self, bad boy!)

However, it is my firm belief that extensions are required and if it means nothing can be placed in the OBEX, then that is to the detriment of Parallax and the rest of us.
So, I restate, another section for non-compliant PropTool code is required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)
· Search the Propeller forums (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

BradC
12-13-2009, 12:31 PM
Phil Pilgrim (PhiPi) said...

heater said...
2) The Prop Tool Spin compiler is not much use. ... It's x86 assembler so it's a non-portable dead end.

That statement puzzles me. 99% of the hardware that users run programs on is Intel x86-compatible


Phil, that's just like saying "Oh well, 99% of computer users use Windows, so we'll only target that". You have just locked out the not-insignificant portion of users that still use PPC Macs, not to mention the ARM based products that are starting to appear.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

Phil Pilgrim (PhiPi)
12-13-2009, 12:39 PM
Cluso99 said...
Parallax have stated they do not intend to add features to the PropTool.

When did they say that? I've been under the impression that there is a to-do list, but that stack items keep getting pushed on top of it. But even if what you state were true, that doesn't mean that a groundswell of demand can't change their mind.

But let's say that it is true, and the language remains frozen — a deplorable state, to be sure. What would be wrong with using your preprocessor to produce a default version for the OBEX that the standard compiler can compile, along with comments for those who need to edit in other options?

-Phil

Phil Pilgrim (PhiPi)
12-13-2009, 12:41 PM
BradC said...
You have just locked out the not-insignificant portion of users that still use PPC Macs...

I have a PPC Mac that I use every day. But I recognize that it's quickly becoming a dinosaur, so it would be disingenuous of me to demand support for it.

-Phil

evanh
12-13-2009, 12:45 PM
The assembly being common or not it not that important. AMD64 is quite a new beast so one could say x86 is on the way out.

evanh
12-13-2009, 12:49 PM
Cluso99 said...
I think GPL has too many restrictions.

For example?

It seems to always come back to just one point - Requiring disclosure. Doesn't seems like lots of restrictions to me.

Sapieha
12-13-2009, 01:04 PM
Hi Chip.

I dont know al rules of Patents that give me no position to talk on that.

BUT Source of Propeller Tools are welcome for me at last.
That in my opinion some structures on usage HUB mem in run BIN file are not usable in advanced programing to spare after RUN as much memory as posible.
With source of Propeller Tools it is posible to me rewrite that portion of code to met new structure that give me back every LONG fre after RUN.

Thanks for considering that posibilityt to os.

Regards
Christoffer J

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Jeffa
12-13-2009, 01:10 PM
I've been using the open source Netbeans www.netbeans.org as an ide for .html, .css, .c, .c++, .php, ruby, ruby on rails, javascript....

I like that for each of the languages I'm using the same editor. And it has some excelent features. It has folding capabilities, (re)formating, code completion, contextual language documentation, project management. It easily integrates with versioning software (I'm using subversion).

It's ported to Windows, Linux, Mac and Solaris.

I don't know a lot about compilers. I do know that when I'm writing ruby code with netbeans that I can run it with an internal run time or the version I had installed on the computer and discovered by netbeans. When I started learning c++ I installed a module easily from the netbeans ide and it setup a wrapper for the cygwin gnu compiler I had previously installed on the computer.

So I'm thinking that netbeans has some part of it's community strictly developing the ide. We or Parallax wouldn't need to recreate that wheel insofar as the editor and and ide framework and spend most of our efforts on the compiler(s). It could support multiple compilers and multiple languages.

Maybe Ken and/or some other Parallax cheiftans could speak to Sun about their support of the netbeans project - advantages and disadvantages of their open source experience. Here is a link to the early history of netbeans http://en.wikipedia.org/wiki/NetBeans#Early_history

GNU or MIT licensing. Wow reading this thread has opened up a lot of new things to think about in that regard. I could spend all my free time just learning enough additional background from what I already know about those licensing schemes, to contribute on that debate. Funny how the more you learn the less you know.... :) Isn't Linux open source? I sure do use Apache httpd, and wordpress, and Drupal, Dokuwiki, mantis, ...

rodaw, - jeffa

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jeff Albrecht - jeffa

---

"There are 10 types of people in the world, those that know binary and those that do not."

potatohead
12-13-2009, 01:25 PM
@OBC: That other "open" micro has caught the attention of several prominent open code / creative commons luminaries. It's no more open than what we have here, but it is price and feature attractive for the purposes of those promoting it.

That's why, IMHO.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Phil Pilgrim (PhiPi)
12-13-2009, 01:43 PM
potatohaed,

That, and the AVR hardware architecture was designed and optimized for C, which some consider to be an advantage.

(LOL! 'Love your new avatar, BTW!)

-Phil

Roy Eltham
12-13-2009, 01:55 PM
Converting 386 assembly code to something else wouldn't be that hard. In fact, if the license is agreeable, I'd be willing to take on the challenge of converting it to C/C++. People could take it from there to anything they wanted.

Regarding the OBEX, I don't see why some of you are so strongly against allowing other languages and formats in there. Why? I think if we have good tools for each language/format, then having OBEX include them is a good thing for the community and for attracting more users. I know some people are turned off by the SPIN/PASM stuff and would rather code the thing in BASIC or Java or Forth or whatever other language. If the OBEX has things in there in the languages they wanted to use then that would be a positive thing that would attract them to using the Propeller.

The alternative path is to have a seperate repository for code using the other languages and format(s). I don't like this option, but if OBEX is locked to it's existing languages/formats, then this will almost definately happen, and I see this as more splintering and negative than just having it all in the OBEX.

This community is full of people that are willing to help and willing to create new variants of OBEX stuff, that eventually most of the good things in there will be available in most of the language and format variants. I see that as a VERY good thing.

I think the key compatibility measure should be that it works on the Propeller, and ideally on the standard Propeller boards sold by Parallax. I don't think the key compatibility measure should be a piece of software that Parallax no longer wants to enhance.


Looking to the future, When the Prop 2 comes out with it's built in developement environment. That one will likely be different from Proptool, and likely much better and supporting many of the things the community here wants. Wouldn't it be cool if we had a reasonably good standard SPIN/PASM extended language/format agreed upon by the community and Parallax with good tools support that could be used as the basis for the Prop 2's SPIN/PASM language/format? I think so...

In any case, OBEX will have to be extended to allow for Prop2's variant of the SPIN/PASM language/format. So are you against that too?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

potatohead
12-13-2009, 02:56 PM
Thanks. It's a test drive right now. I'm liking it a lot. I'm a sucker for goofy animation. I've asked for permission where I found it. Hopefully I get it. Would be a shame to pull it, but I will, if I don't hear back.. (crosses fingers)

C is an advantage for sure, particularly with the crowd promoting it. It's home turf to them, and that's all fine and good. What newcomers are highly likely to find is their ability to progress past the nice little sandbox is going to go rougher than a similar person experiencing the Prop, unless they have some background in those things.

Roy, I see the OBEX as a prime example of less being more.

The limited number of choices actually works to cultivate a pool of object that can really be used. Having COGs -vs- interrupts means being able to do so without having to weave bits of this and that together in complex ways most of the time too. There just isn't a ton of ways to hook things together, meaning there just isn't a lot of understanding of hooks required to actually do it either.

A big part of what makes that all work is the limited, but useful, choices given. The other chunk of that being those choices are really well suited to a lot of the potential project / task scopes people would choose the chip for too.

Adding more choices would just dilute that, and not really bring much value along for the ride.

Which is worth more? Attracting potential new users, regardless of experience, or making experienced ones more happy, when they are also capable of making themselves happy?

New user approaches, and is intrigued, but wary of learning SPIN + PASM. They are shown the OBEX, see that it is actually possible to get a lot of stuff done, and go for it, and are highly likely to see success, and can call a support line even! That's bad *** friendly, and productive too. That's the Propeller sauce right there. Good stuff.

The more experience they have, the more needs they will have come along for the ride, and the more diversity and complexity required to serve them in the same way less complicated users are served.

Which is worth more?

Everybody who has a propeller can use the OBEX, and can 100 percent for certain, build what they find there. If there is a mixed bag in that OBEX, then it's not 100 percent, and that's the value loss.

On the other hand, let's take BST. If there is a BST OBEX, then it's 100 percent for certain people can build what they find there too. The MIT license in the existing OBEX means transcoding existing objects to boot strap the new one too.

If there really are that many users who are just not seeing the value from the existing OBEX, add one that does deliver that value. Seems to me, Parallax could give it the nod, with a link and ready reference for those who ask, or for those who exceed the practical capability of the Propeller Tool. Doing that in no way detracts from the holistic solution we have right now.

That is, Propeller, IDE, Reference Designs, Reference Boards, Documentation, OBEX, Tech Support, and this forum.

When Prop II comes out, I suspect it will be the same thing, with an OBEX to suit that chip. Given the difference in capability, that OBEX will have a complexity scope far beyond the one we have right now. Since Prop I isn't going away, it makes no sense to complicate it, when those needs will be met with the Prop II solution, right?

Prop I will be sold for a very long time, and will be sold while Prop II is being sold as well. The solution is complete, attractive and very productive. What value add is there for Parallax to complicate that, when it can be done by those wanting that complexity anyway?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/13/2009 7:07:34 AM GMT

Phil Pilgrim (PhiPi)
12-13-2009, 03:18 PM
Roy Etham said...
In any case, OBEX will have to be extended to allow for Prop2's variant of the SPIN/PASM language/format. So are you against that too?

Come on, Roy. That's a red herring, and you know it. Of course there has to be a repository for Prop2 code as well.

My objection to polluting the OBEX with language variants results from this hypothetical scenario:

····Ralph writes a widget object using SpinA. People rave about it, so he puts it in the OBEX.

····Gloria writes a whatsit object using SpinB. People rave about that, too, so she puts it in the OBEX.

····Leet has all the compilers: for SpinA, SpinB, and Parallax Spin. He wants to write a program that incorporates
········both widget and whatsit. Leet is royally screwed, though, since no one compiler supports
········both SpinA and SpinB variants.

This will happen if the OBEX is open to all variants. There needs to be a common denominator for the sake of interoperability. If someone is going to write a preprocessor that accommodates their own variant of Spin, that's fine. But it better be capable of outputting vanilla Spin code if they want their users to contribute code to the OBEX.

Here's the deal: Plain vanilla Spin/Assembler may have some shortcomings, but it is a universal language for the Prop, in the sense that anything written in another language can be translated to it. Relocatable, linkable object modules are out, since Parallax wants to promote source sharing. Parallax Spin/Assembler source code is the next best common denominator.

-Phil

Roy Eltham
12-13-2009, 04:30 PM
I was suggesting that there only be one new variant of SPIN/PASM. A variant that the community (including Parallax) could decide on as the one sanctioned for OBEX. And we'd encourage people making development tools that are SPIN/PASM to use that new variant (with preprocessor, etc.) or the original variant. This allows for progress to be made in the SPIN/PASM tools. I think this new SPIN/PASM variant could be where we move towards what will be in the Prop2.

I also support adding other languages such as BASIC and Java to OBEX. To me, wide language support can only be viewed as a good thing. It will bring in more users (more customers for Parallax). I think this should be done regardless of what happens with the PropTool stuff. Yes there might be cases where a particular object might not be available in one or more of the languages. That can and does happen now with C and SPIN/PASM, but the value of having C is greater than this negative. I think the value of having other languages is equally greater. Over time, more C variants of the SPIN modules have been appearing (I remember when the C stuff first went in, there was only a few). This will happen with all of the languages.

I just can't fathom why you guys see this part as negative. You want tools support for as many platforms as possible yet you don't want support for as many languages as possible? It just seems contradictory.

I do understand that if we had every random SPIN variant in the OBEX it would be bad. I just think that having a continually advancing and growing variant is needed and since PropTool isn't going to be doing that and we can't take out PropTool since that's the official one, I think we need two.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

Post Edited (Roy Eltham) : 12/13/2009 8:35:56 AM GMT

heater
12-13-2009, 04:48 PM
OBEX must remain as pure as possible.

It's part of the value proposition of the Propeller, especially for those new to electronics/software or just the Prop.

As soon as someone new to the Prop has to spend a single minute wondering why they can't use that funky widget driver out of the box from OBEX with the Prop Tool Parallax has supplied them you are lost.

If they persevere and find out it's because the objects in OBEX form a mutually incompatible Tower of Babel then you are lost forever.

All this has nothing to do with open sourcing the IDE. It has to do with vetting in some way everything that comes up in OBEX. Even if vetting means simple removing it when enough forum members have pointed out it needs a Java runtime on the Prop to operate or whatever ludicrous
thing comes up.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Nick Mueller
12-13-2009, 04:48 PM
As long as it is 'verboten' to have different dialects in the OBEX, you disallow any progress in SPIN or PASM. But at the same time, you realize that these languages need extensions to enable you to push the Prop's limits even further.
What do you want? Progress or stall?

You find that same contradicting pattern when you want to have an IDE in Prop II's ROM. Progress by freezing designs?

That's a completely new way .......... to FAIL.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

heater
12-13-2009, 04:55 PM
Roy : Yes I agree "To me, wide language support can only be viewed as a good thing"

BUT NOT IN OBEX.

OBEX is that nice simple starting point where someone who hardly knows what a programming language is can work their way through the Prop manual, get something from OBEX and have it work in short order.

As I say, the minute they have to think about a problem which is not part of that process you are lost.

Anyway, how would the Perl guys take to the idea of posting Python code to CPAN?

See what I mean?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

James Long
12-13-2009, 04:55 PM
Roy Eltham said...
I was suggesting that there only be one new variant of SPIN/PASM. A variant that the community (including Parallax) could decide on as the one sanctioned for OBEX. And we'd encourage people making development tools that are SPIN/PASM to use that new variant (with preprocessor, etc.) or the original variant. This allows for progress to be made in the SPIN/PASM tools. I think this new SPIN/PASM variant could be where we move towards what will be in the Prop2.

I also support adding other languages such as BASIC and Java to OBEX. To me, wide language support can only be viewed as a good thing. It will bring in more users (more customers for Parallax). I think this should be done regardless of what happens with the PropTool stuff. Yes there might be cases where a particular object might not be available in one or more of the languages. That can and does happen now with C and SPIN/PASM, but the value of having C is greater than this negative. I think the value of having other languages is equally greater. Over time, more C variants of the SPIN modules have been appearing (I remember when the C stuff first went in, there was only a few). This will happen with all of the languages.

I just can't fathom why you guys see this part as negative. You want tools support for as many platforms as possible yet you don't want support for as many languages as possible? It just seems contradictory.

I do understand that if we had every random SPIN variant in the OBEX it would be bad. I just think that having a continually advancing and growing variant is needed and since PropTool isn't going to be doing that and we can't take out PropTool since that's the official one, I think we need two.


Roy,

I think the point is; a huge amount of possible compilers which may be lacking support. Now we know there are some die hard people here, which are working on items that I personally feel will have great support. Those are not the ones I am personally worried about.

I also think adding Basic and Java would be a great asset. But which Basic are you going to use. I know of two versions being done at this moment (at least I think there are). I can't say which one is better. It's the possible dilution of the OBEX which has Phil and I concerned.

If all the other languages (all unique, and not with a common preprocessor) were available when the Propeller was initially released, how far do you think the propeller would have advanced? It's is possible it would have advanced to the same location. But it is also very possible, the OBEX would be very limited. The vast amount of people using the same language, and feeding from each other is what pushed the Spin and Pasm language to the point it is. Would the propeller have FRSW if there had been 5 different possible IDE's? I don't know, but I do think dilution does slow the advancement of any chip as the propeller.

Power in numbers, and two heads are better than one, are both very real statements. I think the large group will produce the most advancements. They make steps off each other, but only if they are on the same set of stairs. The human pyramid is specific in what language they are communicating with.

I'm not knocking other possibililies, just the idea of dilution of the forward momentum the propeller has had for the last year.

If a different IDE can output the basic native language, I think it will be great. If it is yet another thing to learn to use it's file, it's dilution.

I'm not a "C" person. I'm not going to learn "C" or Java. I don't have enough braincells free for the information. But if that is the way the Propeller eventually heads without native spin support, the chip will be useless to me. That is my major concern. I can use what is existent, but further expansion from others would be dead.

Will you follow if the majority of the OBEX follows a path you are not versed with? That is the major question everyone should consider.

EDIT: I reread my post a couple of times....and it sounds harsh. It is not meant to be. I am just concerned for my own personal use of the Propeller. I jumped out and learned a brand new language to use it, and I do not even want to think about trying to learn another for continued "involvement".

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services (http://www.lil-brother.com)

Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits (http://www.savagecircuits.com). Learn to build your own Gizmos!

Post Edited (James Long) : 12/13/2009 9:07:45 AM GMT

heater
12-13-2009, 04:57 PM
James: Yes indeed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Nick Mueller
12-13-2009, 04:59 PM
> Anyway, how would the Perl guys take to the idea of posting Python code to CPAN?

Or even worse, for different versions of Perl! http://forums.parallax.com/images/smilies/wink.gif


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

Phil Pilgrim (PhiPi)
12-13-2009, 05:31 PM
Nick Mueller said...
As long as it is 'verboten' to have different dialects in the OBEX, you disallow any progress in SPIN or PASM.

'Not so, as long as the extended versions can translate to compatible Spin/PASM source for the OBEX, along with outputting object code. The upgrade game works like this:

1. Define a whiz-bang preprocessor that allows, say, y[ i] := a[i, j] * x[j], and outputs y[ i] := a[i * xdim + j] * b[j].

2. Everybody says, "Wow! Cool, Nick! Multidimensional arrays! We want that!"

3. Demonstrate to Parallax dev team: "See, guys, how this works? And you don't even have to change the interpreter!"

4. Parallax dev team says, "Oh, I don't know. That's a lot of work to add to the compiler."

5. Tech support receives tons of calls: "I really like Nick's multidimensional arrays. Can we have 'em in Spin? Please, please, please, PLEASE?"

6. Tech support reports to dev team: "These calls are driving us crazy! Can't you do something?"

7. Dev team: "Oh, okay."

And, bingo! The boundaries of Spin expand a notch. http://forums.parallax.com/images/smilies/smile.gif

-Phil

Roy Eltham
12-13-2009, 05:33 PM
heater, OBEX already contains SPIN, PASM, and C. It's already got things in it that will not work with the official Parallax PropTool. Are you advocating removing those?

What will happen if OBEX doesn't allow other languages and formats? Another repository will start up. Do we really want two? I know that if OBEX doesn't open up, then I will be advocating just going to a new repository that has everything.

Also, it's pretty trivial for the OBEX site to have filters to just the language(s) you care about. It could even default to only PropTool compatible stuff for new people. The compromise solution I think is a better filter interface, not limiting the contents.

James, I seriously doubt SPIN/PASM will ever NOT be the main language a lot of people use on the Propeller. It's the "built in" stuff. Supporting other languages is not "instead of" its "as well as". As an example, when I first started playing with the Propeller (on the Hydra) the first thing I did was go get the ICCv7 compiler and only used C, since I was already familiar with it and SPIN/PASM was foreign to me. However, over time I learned PASM and a little SPIN, and I find it allows me to do the things I want to do on the Propeller easier. So now I am using SPIN with a lot of PASM and no C at all (however I REALLY miss the preprocessor). Also, really doubt the entire community will switch to one language or another. There will always be objects of all types in there.

Another thing, I don't always use OBEX code as is. I have tweaked them or combined it with my own code to suit my needs. I have also looked at an object to learn how to interface to a particular piece of hardware, and then just written my own version. Sometimes, I'll just use a small snippet of the code. A lot of those objects are pretty specific to a particular hardware setup or combination of sensors, so they require modification before use.

Also, people doing doing this stuff are usually pretty clever and resourceful, I don't think we need to protect them from failure. I mean seriously that's my primary learning mechanism. :) Try, fail, figure out why, try again, and so on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

Sapieha
12-13-2009, 05:38 PM
Hi all.


I not see any problems to have variants .... BUT in that case them must have included ..... IDE/Compiler Tool ... That can compile it !.

Regards
Christoffer J

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

heater
12-13-2009, 05:52 PM
Phil: I know what you mean about a preprocessor producing Spin that is OBEX "standard" Spin.

However in general I think it's a really bad idea.

It may work OK in simple situations like the #ifdefs in BST/HomeSpun but...

In general you can end up with a preprocessor that auto generates piles of unintelligible Spin with little or no comments. Consider the assembler listing output of most C compilers.

I could create a "pre-processor" that takes as input something like:

funky_widget (in_pins = [1,2], out_pins= [3,4], cogs=2, speed=5MHz, inbuff = @somewhere, obuff = @somewhere_else, buff_size = 64);

And produces a few hundred lines of Spin and PASM that runs in 1 or more COGS.
In the nature of code generators it would probably not be easily human readable and lacking in useful comments.

Now I could put a sample of this generators output in OBEX and it may work in that case with the Prop Tool.

But what about all the other millions of permutations of parameters and configurations that it makes possible in that one line of input?

Should I add them all? No. Is even one useful?

This is already an issue with ZiCog's simple use of #ifdef. If I were to put it in OBEX should I just put the Z80 emulator version or the 8080 version. Should it be the HUB RAM version or the external RAM version. If external RAM should it be for the TriBlade or RamBlade or DracBlade or Toby/Blade or Hydra, or Morpheous.

I think this is just leading to an unmanageable mess in OBEX as well.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

potatohead
12-13-2009, 07:05 PM
I'll bet they leave SPIN just as it is until Prop II. I would. The reason being it's complete enough to build on, robust, and feature complete. There are things that would be nice and things that help more advanced projects to be completed, but those things really aren't necessary to grow propeller users, are they? If so, are they for majority growth, or just a fraction?

For those things, good tools have been written, making them possible.

There will have to be a language break at Prop II. There is enough new about it to warrant an advancement in SPIN, and we know of a bunch of stuff in PASM that's seeing changes / enhancements. That seems to be the most logical time to update the whole works.

The way the OBEX is right now, code modules are discrete things to be assembled to achieve a goal. Some of the things being discussed are really whole environments! Would something as complex as the ZiCog, for example, even warrant being in the OBEX, as it stands right now, assuming it could be?

I think another code repository is needed. Not an exchange so much as a full on repository with the features that go along with that. Parallax could give this the nod, and a link for those kinds of users wanting to go into that territory, leaving the very clean, simple, and productive OBEX, and tools just as they are, until such time as it makes sense to add to them.

Here's how I'm getting there:

Why put something in the OBEX?

Is it something that one intends to see reused, or is it to house and maybe validate a project of some kind? The two uses are different.

Most of the object in there right now are discrete things that empower a user to just go hook some stuff up, and get going straight away, or they provide some common functions people would find useful. That's the lego thing, and SPIN is really good at exposing that to a user in a way that just does not carry a lot of baggage.

A repository can hold bigger things, validate projects, empower people to collaborate on projects, and contain things that may need other things, or that are complex environments, etc... Seems to me, if it's not called "Object Exchange" the door is clearly open for these kinds of things to have a stable, central home. Maybe that is the way to go.

I'm wondering just how many users of the Propeller are at the level being discussed here. Is it a nice fraction, silent majority, or just a few alphas?

I don't know, do any of you?

The reason for asking that would be to make a value judgement as to the worth of things. Diluting the strong value seen in the OBEX right now is worth what? If new users find less use value out of it, it's less attractive, and that costs users. Would users be gained on the other end?

Given those kinds of questions, doesn't another repository make total sense, unless the need to have code associated with Parallax rather directly is seen as important. Is it?

re: C Well Parallax sells a C tool for use with the Propeller and that makes sense to host stuff for it in the OBEX. Other tools are not sold and or supported, so why should they be there? That leads right back to the question of worth I posed doesn't it?

I would like to see a repository where bigger, better, faster kinds of projects are housed and grow. Why exactly does this have to occur in the lego style OBEX, and what value add does that have, or is it a net value loss overall?

Edit: Really, having another repository isn't a bad thing! I think that's where I'm at, after reading the thread. Say somebody builds up a nice board. We've got a batch of those now, and that is pushing the OBEX a little, as people have to modify. Of course, getting or building a board means that comes with the territory. In this project repository, the details on ALL of it could be in one place.

Frankly, I think the idea of that is really valuable. Schematics, gerbers, core code to make it go, links to, or actual ports housed there, etc. The norm could be then either one is sticking with the fairly standard stuff, in which case the OBEX is the way to go. That's the supported Parallax path, where it's simple, educational and productive.

When it's time to step outside that little sandbox, somebody somewhere, maybe Parallax, maybe one of us, links them up to the more powerful repository, project exchange, whatever it's called, and people start really going to town. Have a Morpheus, Triblade, etc...? Get linked up with the code that matters, and if you do something great, put it right there!

Curious about your thoughts...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/13/2009 11:26:16 AM GMT

hippy
12-14-2009, 12:37 AM
heater said...
Hippy, please can you explain to me what is the political motivation behind the GPL? I have heard this idea many times but have never understood what it meant.


Political in the sense that it attempts to push developers towards a particular social model of program development, furthers a particular ideology.

You can look at it from an IP perspective - Traditional closed source is "mine, mine, mine", no one has any access to the IP and it's protected vigorously, 'GPL' protects its IP vigorously but with a we'll share IP as long as you are willing to share yours clause, 'MIT' people don't care about IP, will share it with anyone. GPL is political as a social model in that it has an ideology in common with closed source that IP should be restricted, as against IP being a common treasury all can take from.

There are really five social / ideological models -

Unrestricted Open Source (MIT) : Don't care what anyone does with it.

Restrictive Open Source (GPL) : Preventing derivatives unless also similarly licensed.

Open Source API : The source is closed but the API, interfaces, file formats etc are published and may be used freely.

Restrictive Closed Source (NDA) : The source can be viewed but there are restrictions on using that source.

Entirely Closed Source : No one gets to see the source, reverse engineering excluded by EULA etc.

----

On the issue of divergence of tools and IDE's should the sources be released that's largely a red herring. Not releasing the source hasn't stopped that happening already, and nothing can unless Parallax starts to 'get heavy' over IP which I cannot see happening.

jazzed
12-14-2009, 02:21 AM
MIT license as used here is also "Political" in terms of distribution of wealth where "the currency" is credit for work propagated by copyright statements (and if you don't provide some kind of copyright in OBEX, you can get a nasty note). This is of course different from GPL in that one is not forced to disclose source code for entire integral and derivative binary works .... Of course binaries are seldom shared around here or sold anywhere, but they could be.

On additional OBEX: Seems to me that major projects should have their own forum page, wiki page, or external website. That allows a coherent way to keep information and allow for discourse rather than having dozens of threads with dozens of thread pages in one place.

Phil Pilgrim (PhiPi)
12-14-2009, 03:38 AM
heater said...
In general you can end up with a preprocessor that auto generates piles of unintelligible Spin with little or no comments.

True enough. That's why the original code that spawned it needs to be included in the processed source as a comment.

The issue of conditional compilation and the various code permutations it's capable of generating is a bit stickier. To me it cries for a solution from Parallax. I mean, if PBASIC can support conditional compilation, why can't Parallax's flagship Spin language?!! But, as it turns out, Parallax recognizes (or recognized) the need for this, among other preprocessing capabilities:


In May of 2007, Paul Baker (Parallax) said...
We recognize the need for pre-processing capabilities, however to arrive at the best solution we will need to spend some time deliberating on it.

Two and a half years is a lot of deliberating, so I expect the outcome will be breathtakingly steller! Hopefully, the result will include a way to specify an external preprocessor in the source, say, in a PRE section, so different objects can use different preprocessors, as spec'd by their authors. This would ease any OBEX incompatibilities, and there could be a special section in the OBEX for people to post their own preprocessors.

-Phil

P.S. I know this discussion has meandered down the garden path into OT territory. But I believe it's a natural consequence of considering this: If the dev tools are made open source, will this lead to a plethora of derivative dev tools and, if so, what are the consequences for the OBEX? I believe that Parallax can minimize those consequences by providing the features up front that independent developers would be sure to include, or at least by building in hooks that developers can use to expand the compiler's capabilities natively. This doesn't address cross-platform issues, of course. While it would be nice if Parallax could address these issues internally, from what I can tell, that may be an unrealistic expectation.

Nick Mueller
12-14-2009, 04:04 AM
> If the dev tools are made open source, will this lead to a plethora of derivative dev tools and,..

No, it won't. One or two will survive and all change-requests will be well designed, discussed and decided in the forum.
Different IDEs could even use one (THE one) compiler written in C.

There'll be people who focus on PASM, some on SPIN and others on the look&feel of the IDE.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO (http://www.yadro.de)

Roy Eltham
12-14-2009, 05:29 AM
I wonder if the lack of progress on PropTool is because no one at Parallax wants to work on it anymore? I know Chip is kind of anti-Windows.

I should see if they are open to someone external doing updates, primarily preprocessor support. Someone could update the tool and the documentation, and then all they would have to do is distribute/support that updated version instead of the current one.

If we had preprocessor support in the "base" SPIN/PASM language, then variants could be supported via predefined preprocessor settings in each compiler/tool. Then OBEX could have one object that via defines works on standard PropTool or popular variants. Then OBEX could require that objects work with PropTool at least, but they could work with variants too.

Ken, are you guys open to that? I think we could work something out that would have low impact on you guys.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

Phil Pilgrim (PhiPi)
12-14-2009, 05:43 AM
Roy, I agree: something could/should be done along these lines. I think the variant preprocessors need to be specified in each object's source, however, so that a program can be built from objects that compile using different preprocessors. This would solve the "Tower of Babel" problem in the OBEX, if the preprocessors were available there, too.

There's still an issue remaining: Ralph creates a preprocessor and posts it in the OBEX. Sarah uses that preprocessor with an object she contributes to the OBEX. Ralph upgrades his preprocessor and uploads it to the OBEX. But Ralph's revisions break Sarah's OBEX code. The solution to this is more administrative than technical, I suppose. It may require that any preprocessor upgrade cannot replace one that's already in the OBEX but has to be uploaded under a different name.

-Phil

potatohead
12-14-2009, 05:48 AM
I think it's a matter of resource / return.

If the prop tool sees changes, like conditionals, it seems to me the best idea, from a resource / return standpoint, is to defer those until Prop II, where the changes will then be necessary. Right now they aren't. It's a nice to have, but not necessary.

Part of the value of the prop is the low noise level, low complexity programming environment. Increasing that noise level for users already using gets what in return?

IMHO, that value judgement is what drives this, not any lack of desire to work on things, or other negative things. As a user community, we've demonstrated other tools can and have been written, which actually deal with that matter, leaving Parallax to focus on feature / value return kinds of things. Innovating to Prop II outweighs all of these things at this time. I believe this because I believe the majority of Propeller users are well served by the tools at hand right now.

One other factor is stability as well. What is there is nice and stable, consistent, and productive. Making changes will lower that some, without a significant return at this time. Put another way, say a few man weeks were devoted to the prop tool, and a few features many want appear. We are happy then, but do we buy more Propellers? Does that feature list bring in the "on the fence" masses out there, if they even exist?

I suspect not, but I don't know that. Does anyone? If so, make your case, as that value proposition would then warrant changes now and carry weight, IMHO.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

potatohead
12-14-2009, 05:52 AM
Phil, that dilemma requires a managed software body to resolve. IMHO, that's one primary reason for the minimal tool set being the reference and authoritative one. It takes a very significant human investment to keep that kind of thing sorted, and where is the return for Parallax on that? Frankly, where is the return for most users in that?

I am operating under the assumption that most users are not in serious need of that level of functionality. Am I wrong on that one?

On the other hand, if there is enough use value there, that warrants a project exchange where things of greater complexity can be managed by those that derive sufficient value from them to warrant the effort. IMHO, that is the strongest case for a secondary repository, with some features above and beyond simple code vaulting. This community could really build some value with that.

I suspect also that dynamic is exactly why the code to BST is not released at this time. Added burden, no significant return = not optimal case use value for the investment. Brad? I'm very curious about how you think on that.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Phil Pilgrim (PhiPi)
12-14-2009, 06:00 AM
potatohead said...
I am operating under the assumption that most users are not in serious need of that level of functionality. Am I wrong on that one?

Maybe, maybe not. But that's the wrong question. The right question is, "Are the users responsible for the highest sales volumes in need of this functionality?" (Parallax is a for-profit corporation, after all.) If these are capabilities that, say, OEMs might want, and if lack of them drives them away, that's a problem. The nice thing is that anything done for the volume purchasers trickles down to benefit the rest of us.

-Phil

potatohead
12-14-2009, 06:16 AM
Well, that's exactly where I'm headed with that.

I do this all the time.

That's a wants -vs- needs problem. Have those users phoned it in, saying they can't buy because of missing feature x, or do they just want it?

if they are not buying, how much are they not buying, and does that balance the current lean implementation and the value associated with that? I've not seen data that supports a enhancement favorable answer. I don't even know whether or not Parallax collects it either. I would be surprised if they didn't however.

The other elephant in the room is qualifying that "not buying" statement. The real test is a flat out sales deal. Put it right back on them with, "if we do this, what annual number can you commit to?"

I'll operate under the assumption that those calls are not occuring, and or if they are, scheduled to be addressed by Prop II, as Prop I has other limitations besides some nice to have programming tool enhancements. I'll bet I'm right on that score, meaning we are talking about people already using propellers much more than we are talking about potential propeller users.

That means it's a want kind of thing, not a need. Completely different dynamic.

If they are getting good value now, they won't walk away on a want. If they are not, then they probably are waiting on larger projects, and that goes back to the query above.

Also, tools are available now that address those wants, so why not use those? It's not like users at that level would be afraid of, or capable of authoring and or using other tools. If the value is there, they will do it actually. Why leave something on the table, if it's possible?

That decision tree isn't biased toward "have to do it right now", IMHO which is why it isn't happening.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/13/2009 10:23:42 PM GMT

Roy Eltham
12-14-2009, 06:20 AM
potatohead, adding a preprocessor to the PropTool would only "add noise" if it was used. Existing code would not need to change at all. However, adding a preprocessor would make it easier to support multiple hardware platforms (Parallax has several Prop based products with differing hardware setups just themselves, without even factoring in all the community hardware projects.) in one object. It would make it easier for a new user to use objects if they just worked with the hardware they had without needing any edits.
Also, I am proposing an external person (like myself) do the update for Parallax in a contracted way that allows the external person to gain full access to all the stuff needed to make a full build. I'd be willing to undertake the task for minimal cost (potentially even free).

Phil, I was talking about building a preprocessor into the PropTool. Not having it be external. And really, I don't think we need multiple preprocessor flavors. I'm sure we could all agree on a standard syntax (probably the same as the one in the C Parallax sells for the Prop). Once you have the basics, it's easy to wrap advanced stuff for perticular tools in a basic #ifdef. There would be no need to multiple preprocessor tools being put on the obex.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

potatohead
12-14-2009, 06:24 AM
How is that different from the alternative we have now? It is possible now to author for multiple things, and do so for free. The tools exist, so what value does having them embedded in the Prop tool bring now, that won't be there for the revision that must come with Prop II?

How would that external person make sure their changes align with the design of Prop II, so as to prevent dead end changes that then must be managed as noise for the longer term?

(and I'm on the Devils advocate side right now, because I'm interested in the business element in this, and how that plays out in this industry, compared to my own, just FYI Edit: And doing so makes your case stronger, I might add :) )

Another Edit: Perhaps this might help to see why I'm asking what I am asking.

Operating ahead of the design carries risk. Either those that want to operate there carry that risk, or Parallax does. Risk equals dollars, so what is worth what?

If somebody wants to use the tools developed by the community, there is some risk in that the eventual change to come from Parallax might require some re-work to best leverage the new tools. At that time, people can pay the price to move over to the new tools, or continue on the path they are on, and carry the load for incorporating Prop II into those tools.

On the other hand, Parallax being involved right now might commit to some things that become awkward after Prop II is realized?

What makes owning that worth it for them? That's where I'm at on this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 12/13/2009 10:37:10 PM GMT

Phil Pilgrim (PhiPi)
12-14-2009, 06:30 AM
Roy Eltham said...
And really, I don't think we need multiple preprocessor flavors.

I respectfully have to disagree. The availability of preprocessor hooks would allow the kind of experimentation that could, ultimately, produce useful new capabilities in the PropTool itself. Without that, we're left with your "I'm sure we could all agree..." part which, if the forum is any indication, is an impossible dream.

What I would like is for the PropTool to be a fertile petri dish for trying new things with the language. If Parallax wants openness and the benefits it brings, this would be an important first step.

-Phil

Roy Eltham
12-14-2009, 06:34 AM
If the PropTool supports a preprocessor, then we can put object son OBEX that work with variant tools and hardware without editing.

A standard preprocessor (like one using in most compilers) would work. This is would align with a prop ii compiler easily. The external person would obviously follow any rules Parallax would have.

I am talking about #define, #if, #ifdef, #ifndef, #else, #endif, #include, and the details that go along with that. It's a pretty common and standard thing in most compilers, and most of it is completely compatible across different compilers all over the place. Obviously, the real powerful part comes with macro expansion.

I am not talking about something that would change the language itself. As in, take one SPIN variant and preprocess it into another. You wouldn't need that to support variants in a single object though, if you had #ifdef blocks and/or macro expansion.
Yes you could "effectively" change the language via macro expansion, but that's not the same as what I think you were thinking.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

potatohead
12-14-2009, 06:36 AM
Phil, doesn't that petri dish then conflict with simple, consistent, productive, rapid learning, robust?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

Phil Pilgrim (PhiPi)
12-14-2009, 06:44 AM
potatohead said...
Phil, doesn't that petri dish then conflict with simple, consistent, productive, rapid learning, robust?

Not if you don't use it. But still, if a preprocessor could deconstruct something like:

DEBUG "The value of X is: ", DEC3, x, CR

into it's constituent FullDuplexSerial method calls, what's complicated and unproductive about that?

-Phil

BradC
12-14-2009, 09:09 AM
potatohead said...

I suspect also that dynamic is exactly why the code to BST is not released at this time. Added burden, no significant return = not optimal case use value for the investment. Brad? I'm very curious about how you think on that.


There are a couple of reasons I've not released the code for bst. The first is this (and I've said this, over, and over, and over again) :

As I started to write the compiler I built what I considered to be an appropriate framework. Not having any idea as to what I was doing, that very well structured framework turned out to be rather inappropriate and gradually devolved into a pile of soggy noodles. The IDE was started along the same lines, and quickly became quite complex as I had to work around various issues on various platforms.

*None* of the code is commented aside from the odd line noting what bug I fixed, where and why.

The main ide form :



brad@bklaptop2:/tracks/devel/Projects/Pascal/bst/ide$ wc -l bstmain.pas
3576 bstmain.pas




The compiler tells me I have 29,687 lines of code between the compiler and the IDE. No comments. None. Very little structure and a great deal of mess.

The toolchain to build all 4 versions is 1.5GB and takes me about 4 hours to build in two parts (compilers and widgetset libraries). As a consequence I don't update the compilers very often.

So, before I release the code I need to restructure a lot of it and clean it up. I progress that slowly as time allows, and I've finally put the whole shebang into source control so I can manage my changes a bit better and progressively make things less ugly. It's all a long process and not one I put a lot of time into as it's just not a priority for me.

To get back to your original question, yes, I want as little overhead as possible. Right now I have a tool set I can use comfortably.
I'm slowly working on new features and additions, but it's all related to what time I can actually spend. Bug fixes always get priority.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

evanh
12-14-2009, 09:58 AM
hippy said...
Political in the sense that it attempts to push developers towards a particular social model of program development, furthers a particular ideology.

You can look at it from an IP perspective - Traditional closed source is "mine, mine, mine", no one has any access to the IP and it's protected vigorously, 'GPL' protects its IP vigorously but with a we'll share IP as long as you are willing to share yours clause ...

It's really just functional. They all are just a function of coordination and business. Some choose to force non-disclosure, because the job is supposedly finished. And some choose to force disclosure which is about the function of making use of the human skills at hand, making progress. Because the job isn't finished at all.

BTW, The bottom three of you list are all compulsory non-disclosure licensing models. Releasing an API is only done out of necessity and is removed once it's not necessary.

The GPL recognises the reality that if cheating is allowed then cheating will occur. And, if left unchecked, will ruin it for all. That's your social component. RMS also recognised the usefulness of cooperation and rests his arguments on the well proven collaborative results of university based research.

I'm not saying the GPL is best for everything. Just that it most definitely is NOT a political or even ideologically based license. Saying the GPL is ideological has clearly been a bit of political suggestion (spin) by some marketroids that realised compulsory disclosure is entirely incompatible with their preferred nice and tidy compulsory non-disclosure.

potatohead
12-14-2009, 10:16 AM
I'm not sure I agree on the non-ideological bit. And I realize this is academic, but a quick on things like "The Right To Read" by RMS, reveals some core ideology there that is not a given throughout our history. Oppressive governments all leverage education as much as they do religious dogma and economics to maintain their (unjust) power.

Right now, those same matters are playing out as very large corporations seek dominance for their ends, not ours. Some would argue that dominance brings us a lot of value. I'm not there, but totally see the case for that. Really, for me it all comes down to basic equality and trust. Without equality being a core reality, some of us are simply better, or more entitled than the rest of us, by virtue of their being. That's all a rather depressing state of affairs. Without trust, the case is made for dominance and repression being necessary things to check the evil inherent in people.

Open resonates on both of those levels, and is more than a functional, or economic thing, IMHO. And the GPL is not only about open, but insuring that once open, always open so that those that own it, really do, in fact, actually own it and can trust it. Neither of those are easily known true when something is closed, without that "right to read".

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net (http://propeller.wikispaces.com/Join+us+on+IRC%21/)
Safety Tip: Life is as good as YOU think it is!

evanh
12-14-2009, 10:24 AM
I think you just answered your own question. RMS's supposed ideology on matters like "right to read" is based on logically thinking about where we are heading. He's just making it a little easier to get there. :)

I'm late for work now. :(

heater
12-14-2009, 03:39 PM
Hippy on GPL : "Political in the sense that it attempts to push developers towards a particular social model of program development, furthers a particular ideology"

Heater on pretty much any other licence : "Political in the sense that it attempts to push developers towards a particular social model of program development, furthers a particular ideology"

I can use some "widget" library from, say, Microsoft. I find I don't get the source. Probably can't give it to others. Probably not allowed to reverse engineer it. May or may not be encumbered with patents and license restrictions. I'm not supposed to hack it or change it. I can't discuss it's inner workings with anyone. I can't have the fun with it we have here endlessly discussing and exchanging bits of Propeller code.

I could say that that is all "socially divisive". It says "We develop, you lowly worms do not. We don't want you to. We want you to buy our stuff. Now and forever. We don't want you to learn from what we have done or share your knowledge with anyone else."

It's like the stone masons guilds of old. About as political as you can get.

The GPL is NOT. No one is struggling for power and money with that.

OK rant over:)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 12/14/2009 7:49:58 AM GMT

Roy Eltham
12-14-2009, 04:17 PM
The license I like the most is the zlib license. It's what I consider the most free while still protecting the original software and authors. I don't think it has any political agenda, nor any significant requirements of the users.

Here's the full terms:

Copyright (c) <''year''> <''copyright holders''>

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.

3. This notice may not be removed or altered from any source
distribution.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki (http://propeller.wikispaces.com/)·and contribute if you can.

Peter KG6LSE
12-14-2009, 04:34 PM
My $02.

The reason I LOVE Parallax STAMP's is because there is a sweet editor for Mac and Linux .
I HATE bare PICs because there dev system is so much more annoying and is NOT user friendly ..

I must give a shout out to BradC for starting on a usable IDE for Props . I could not tell but does it have a GUI like the Mac STAMP editor? ..

i dont hate windows but I don't see why in a modern times we don't have company's just Dev for WIn OSX and " RPM and DEB GNU/Linux"
based system from day 1 .....

I dont need a WinTel box for any thing I do in the rest of my computer life .. so I dont see why I must own a flavor of OS just to learn and build things .

Last I checked Apple had 91% market share in the greater then $1000 market ! .. and they have 14% over all ..
this is potential costumiers who are not able to easly use the Prop chip ...



most major distos of Linux can read a RPM or DEB . pre compiled ...
as for PPC on MAC I too own a TON of PPC gear but If i had to chose between a No OSX and Just x86 I would choose the latter .


this would cover %99 of new systems out there ..



/ rant

Peter KG6LSE

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Carpe Ducktum" "seize the tape!!"
peterthethinker.com/tesla/Venom/Venom.html (http://peterthethinker.com/tesla/Venom/Venom.html)
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway. —Tanenbaum, Andrew S.
LOL

Post Edited (Peter KG6LSE) : 12/14/2009 8:41:06 AM GMT