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.
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.... [noparse]:)[/noparse] 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."
@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.
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·and contribute if you can.
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?
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.
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·and contribute if you can.
Post Edited (Roy Eltham) : 12/13/2009 8:35:56 AM GMT
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.
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
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.
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".
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[noparse][[/noparse] i] := a[noparse][[/noparse]i, j] * x[noparse][[/noparse]j], and outputs y[noparse][[/noparse] i] := a[noparse][[/noparse]i * xdim + j] * b[noparse][[/noparse]j].
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. [noparse]:)[/noparse] Try, fail, figure out why, try again, and so on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
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.
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:
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.
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!
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.
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.
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.
> 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
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·and contribute if you can.
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.
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.
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.
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.
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.
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·and contribute if you can.
Comments
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
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.... [noparse]:)[/noparse] 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."
That's why, IMHO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
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
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·and contribute if you can.
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!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/13/2009 7:07:34 AM GMT
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
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·and contribute if you can.
Post Edited (Roy Eltham) : 12/13/2009 8:35:56 AM GMT
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.
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
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.
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
Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
Post Edited (James Long) : 12/13/2009 9:07:45 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Or even worse, for different versions of Perl!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
1. Define a whiz-bang preprocessor that allows, say, y[noparse][[/noparse] i] := a[noparse][[/noparse]i, j] * x[noparse][[/noparse]j], and outputs y[noparse][[/noparse] i] := a[noparse][[/noparse]i * xdim + j] * b[noparse][[/noparse]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.
-Phil
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. [noparse]:)[/noparse] Try, fail, figure out why, try again, and so on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
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
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 = [noparse][[/noparse]1,2], out_pins= [noparse][[/noparse]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.
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!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/13/2009 11:26:16 AM GMT
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.
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.
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:
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.
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
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·and contribute if you can.
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
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!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
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!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
-Phil
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!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/13/2009 10:23:42 PM GMT
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·and contribute if you can.