1. Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ck?ester.?om> May 15, 2008
- 1032 views
ChrisBurch2 wrote: > c.k.lester wrote: > > So, somebody set up a Euphoria Developers forum and those who care about > > Euphoria development can join. > Absolutey bang on the nail CK. A developers group should be split off. I nominate http://www.assembla.com/ to host the developer's group. :) It is faster than SourceForge and free. I don't know if it's as feature-rich, but it looks like it has all we need. But you guys can look it up and compare. I am using Assembla for BBCMF development.
2. Re: Euphoria Developers Group Discussion
- Posted by Derek Parnell <ddparnell at ?igpond.com> May 15, 2008
- 1028 views
c.k.lester wrote: > > > So, somebody set up a Euphoria Developers forum > I am using Assembla for BBCMF development. But the sourceforge site is already established and workable. What would be the incentive to move to yet another 'forum'. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
3. Re: Euphoria Developers Group Discussion
- Posted by Mike777 <anon4321 at g?ail.?om> May 15, 2008
- 1019 views
Derek Parnell wrote: > > c.k.lester wrote: > > > > > So, somebody set up a Euphoria Developers forum > > > I am using Assembla for BBCMF development. > > But the sourceforge site is already established and workable. What would be > the incentive to move to yet another 'forum'. "Use Assembla spaces for rapid software development, and agile team collaboration. Get free workspaces with unlimited team size and integrated tools like wiki, discussion, alerts, chat, ticketing, Trac, Git and Subversion." Mike
4. Re: Euphoria Developers Group Discussion
- Posted by Jeremy Cowgar <jeremy at co?g?r.com> May 15, 2008
- 1034 views
Derek Parnell wrote: > > c.k.lester wrote: > > > > > So, somebody set up a Euphoria Developers forum > > > I am using Assembla for BBCMF development. > > But the sourceforge site is already established and workable. What would be > the incentive to move to yet another 'forum'. > I would stick with what we have. However, I'm not sure the "EDG" is the answer either. We've always had one, sorta. A few of us developers have talked via email about such a thing and we agree that we do not want the Euphoria community to feel as though the "Elite" drive the direction and leave the Euphoria community in the dark. Sure, anyone can join the list, but do you want to filter through all the nitty gritty of development questions dealing with implementing things internally like what does Line 605 do of parser.e just to pick up on one idea of a new feature? And at that, one feature that is suggested and then subsequently put aside due to it being a bad idea or whatever? I suspect that many people would join in with the EDG and initially it would seem like a good idea, but eventually it will be one or two people max posting on the list/forum/whatever. And their questions will go like this: What do you think of feature ABC? Day 1, day 2, day 3... "Yeah, that's nice..." day 4, day 5, day 6. "Um, should I do it?", day 7, day 8, day 9, etc... I don't think that solves anything and from my experience in Open source development as well as closed source development it's not a matter of if this will happen, it's a matter of if it is 2, 3 or 6 weeks from now. -- Jeremy Cowgar http://jeremy.cowgar.com
5. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ck?ester.co?> May 15, 2008
- 1011 views
Derek Parnell wrote: > c.k.lester wrote: > > > > So, somebody set up a Euphoria Developers forum > > I am using Assembla for BBCMF development. > But the sourceforge site is already established and workable. "Established" is debatable, in that only a few people use it. I think we could afford to move now, if we wanted to. The incentive would be: better interface and faster server. HOWEVER, I'm not against using SourceForge; in my dreams, we're using something better, though. :)
6. Re: Euphoria Developers Group Discussion
- Posted by Mike777 <anon4321 at gmail.c?m> May 15, 2008
- 1006 views
Jeremy Cowgar wrote: > > Derek Parnell wrote: > > > > c.k.lester wrote: > > > > > > > So, somebody set up a Euphoria Developers forum > > > > > I am using Assembla for BBCMF development. > > > > But the sourceforge site is already established and workable. What would be > > the incentive to move to yet another 'forum'. > > > > I would stick with what we have. However, I'm not sure the "EDG" is the answer > either. We've always had one, sorta. A few of us developers have talked via > email about such a thing and we agree that we do not want the Euphoria > community > to feel as though the "Elite" drive the direction and leave the Euphoria > community > in the dark. > > Sure, anyone can join the list, but do you want to filter through all the > nitty > gritty of development questions dealing with implementing things internally > like what does Line 605 do of parser.e just to pick up on one idea of a new > feature? And at that, one feature that is suggested and then subsequently put > aside due to it being a bad idea or whatever? > > I suspect that many people would join in with the EDG and initially it would > seem like a good idea, but eventually it will be one or two people max posting > on the list/forum/whatever. And their questions will go like this: > > What do you think of feature ABC? Day 1, day 2, day 3... "Yeah, that's > nice..." > day 4, day 5, day 6. "Um, should I do it?", day 7, day 8, day 9, etc... > > I don't think that solves anything and from my experience in Open source > development > as well as closed source development it's not a matter of if this will happen, > it's a matter of if it is 2, 3 or 6 weeks from now. You have hit upon the essential conundrum. If there is enough traffic which is development related to be distracting (and, in fact, offputting) to those who have no interest in such things, it is best to bifurcate. If, OTOH, combined traffic is light it is actually a positive (from the perspective of those just peeking their head in for a quick look see) to have all traffic on one list. It implies a certain robustness in the community. I can certainly tell you that one of my concerns about Euphoria when I first looked into it was whether the community offered support to newbies or whether it was hostile to them (as ANY developer's forum will appear, whether or not true). A relatively active forum (as this was at the time, although it pales in comparison to how active it has become) provided me with a glimpse of both and, obviously, satisfied my concerns. With that said, I am strongly in favor of bifurcation. Certainly the current level of wheat to chaff for a newbie is offputting. And you want your support forum to be as welcoming as possible if your goal is to invite Mr. Coder (which I consider myself to be, BTW). Keep in mind that any decision to bifurcate needn't be permanent. Heck, it doesn't even have to be consistent. Things can be discussed on the general forum until it makes sense to move things to a secondary avenue for detailed further discussion amongst the interested. I submit that the time to set up the secondary venue is right now, when developer traffic is high and is likely to continue that way for at least the next few weeks. Sort of a beta, if you will. If it won't fly now, it will never fly. Whether it keeps flying in the inevitable slow down to come is irrelevant to me. If it does, great. If it doesn't, that doesn't mean it won't necessarily revive itself when 5.0 is being actively considered. $0.02 Mike777
7. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at c??ester.com> May 15, 2008
- 1006 views
Jeremy Cowgar wrote: > Derek Parnell wrote: > > c.k.lester wrote: > > > > > So, somebody set up a Euphoria Developers forum > > > I am using Assembla for BBCMF development. > > But the sourceforge site is already established and workable. What would be > > the incentive to move to yet another 'forum'. > I would stick with what we have. However, I'm not sure the "EDG" is the answer > either. We've always had one, sorta. A few of us developers have talked via > email about such a thing and we agree that we do not want the Euphoria > community > to feel as though the "Elite" drive the direction and leave the Euphoria > community > in the dark. I don't view it as the "Elite," but as those who have the time and inclination to make sure Euphoria is the best it can be. This idea of the Elite is silly. All Euphorians would have input, anyway. It's just that development discussion would primarily be by those who 1. have the skillset 2. have the motivation 3. have the desire > I suspect that many people would join in with the EDG... I doubt it. You get very little response here on EuForum when asking for ideas... maybe a core group of 5-10 people (out of how many Euphoria programmers?). > seem like a good idea, but eventually it will be one or two people max posting > on the list/forum/whatever. And their questions will go like this: > > What do you think of feature ABC? Day 1, day 2, day 3... "Yeah, that's > nice..." > day 4, day 5, day 6. "Um, should I do it?", day 7, day 8, day 9, etc... Unlikely doomsday scenario. :) Current development with EuForum and IRC is rather rapid. I'm just tired of y'all trying to get the approval of people who don't really care anyway (by which I mean they don't care how good you make Euphoria, not about Euphoria itself). > I don't think that solves anything and from my experience in Open source > development > as well as closed source development it's not a matter of if this will happen, > it's a matter of if it is 2, 3 or 6 weeks from now. A Euphoria Developers Group can be quick and agile, so that it's more often 2 weeks and not 6 weeks.
8. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at cklest?r.?om> May 15, 2008
- 1018 views
Mike777 wrote: > > > With that said, I am strongly in favor of bifurcation. Mike777 +1
9. Re: Euphoria Developers Group Discussion
- Posted by yuku <yuku at ikitek.?o?> May 15, 2008
- 1024 views
c.k.lester wrote: > > Mike777 wrote: > > > > > > With that said, I am strongly in favor of bifurcation. > > Mike777 +1 Mike777 += 1 Certainly new-users should not be overwhelmed by language developer issues.
10. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ck?ester.com> May 15, 2008
- 1019 views
yuku wrote: > > Certainly new-users should not be overwhelmed by language developer issues. And I wonder what sort of impact and draw v4.0 will have, now with its new standard lib, Linux distributions, etc... Should we expect an influx of new users? Regardless, we need a separate developers forum.
11. Re: Euphoria Developers Group Discussion
- Posted by Jason Gade <jaygade at yah?o?com> May 15, 2008
- 995 views
Heh. I've read the whole thread but I'm just now responding. I like this list, really. It's a simple and straightforward interface. However. A forum is a good idea in order to keep the regular users and user/developers together in the same place but where each has their own subforum. One problem, though, is keeping the community all in one place. I think that is why previous attempts have failed. And I know that's why /I/ stay here instead of dealing with the wiki and other stuff. I've registered at the two forums set up for Euphoria, and even posted a couple of times. But right now I don't even remember the addresses, because all of the activity occurs right here. So that's my point -- it would be nice to keep the development stuff separated from the user/beginning user stuff, but it doesn't work if it's not still all in one place. IMO. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
12. Re: Euphoria Developers Group Discussion
- Posted by Jeremy Cowgar <jeremy at ??wgar.com> May 15, 2008
- 1034 views
c.k.lester wrote: > > And I wonder what sort of impact and draw v4.0 will have, now with its new > standard lib, Linux distributions, etc... Should we expect an influx of new > users? > > Regardless, we need a separate developers forum. Ok, what will we discuss on this developer forum? So far what has been discussed on EUforum are new ideas. Should the developers on this forum just decide that enums are a good thing and develop it w/no input from the EU community? Or optional then/do's? On EUforum we have not went into source level details. There have been email conversations amongst developers w/source level details, we have not done any of that on the forum. I do not think that communication amongst developers is the problem with direction for Euphoria. Direction is what we are really talking about. Not communication amongst developers. A developers mailing list will solve the problem of someone occasionally hitting Reply instead of Reply-to-all. We need direction and better organization. Yes, that comes through communication, but it's only 1 part. Now, you did recommend an organization tool in the start, which is beneficial, if used, and it should be the focal point of this discussion. I think we are already on SF, we should use the tools given to us. SF is at times terribly slow, in fact, I hate using the wiki there, I literally wait all the time for the pages to come up and it's not me, it's SF. But, we can deal with that. Now, back to discussion. The discussion on the forum has been flying, but we are on the brink of a brand new release. The forum will always increase in activity during these times. We do not want a new user coming to see Euphoria and look at the user forum to find the last post was 3 days ago, or that there is 2 posts today, 3 posts yesterday, the prior day no posts, etc... -- Jeremy Cowgar http://jeremy.cowgar.com
13. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at cklester.co?> May 15, 2008
- 1006 views
Jeremy Cowgar wrote: > c.k.lester wrote: > > And I wonder what sort of impact and draw v4.0 will have, now with its new > > standard lib, Linux distributions, etc... Should we expect an influx of new > > users? > > Regardless, we need a separate developers forum. > > Ok, what will we discuss on this developer forum? Changes to the core, including standard libs. These are things that newbs aren't interested in and could be overwhelmed by. > So far what has been discussed > on EUforum are new ideas. Should the developers on this forum just decide that > enums are a good thing and develop it w/no input from the EU community? That's the funny thing... ONLY developers are getting involved anyway. How much input are you seeing here? I'm only seeing a few involved. On a whole, I think the community trusts those who are interested in developing Euphoria... or they're too busy coding. :) Changes to the interpreter do not require community input except when those changes will introduce breaks with old code or will in some way harm the current performance of Euphoria. Otherwise, it's just another feature they can decide to use or not use. What developers should do is discuss among themselves implementation details, then present a vote to the community... MAYBE. As above, most changes can be done without consulting the general population... and I don't think they'll care! It's just another feature they can decide to use or not use. > We do not want a new user coming to see Euphoria and look > at the user forum to find the last post was 3 days ago, or that there is 2 > posts > today, 3 posts yesterday, the prior day no posts, etc... Why not? Stability and a smart userbase is a good thing. ;)
14. Re: Euphoria Developers Group Discussion
- Posted by Jeremy Cowgar <jeremy at cow??r.com> May 15, 2008
- 1032 views
c.k.lester wrote: > > What developers should do is discuss among themselves implementation details, > then present a vote to the community... MAYBE. As above, most changes can > be done without consulting the general population... and I don't think they'll > care! It's just another feature they can decide to use or not use. Is this what users want? -- Jeremy Cowgar http://jeremy.cowgar.com
15. Re: Euphoria Developers Group Discussion
- Posted by Mike777 <anon4321 at ??ail.com> May 15, 2008
- 1027 views
Jeremy Cowgar wrote: > > c.k.lester wrote: > > > > And I wonder what sort of impact and draw v4.0 will have, now with its new > > standard lib, Linux distributions, etc... Should we expect an influx of new > > users? > > > > Regardless, we need a separate developers forum. > > Ok, what will we discuss on this developer forum? So far what has been > discussed > on EUforum are new ideas. Should the developers on this forum just decide that > enums are a good thing and develop it w/no input from the EU community? Or > optional > then/do's? As primarily a user, I think the answers are basically: Whatever makes sense for developers to discuss amongst themselves. You have indicated below that there are some conversations which are held via email. In an open source world, that is quite an indictment. If the reason is that it seemed to be too detailed for discussion on the Forum you have made one of the strongest arguments to making a better venue available. Yes, enums should be in the hands of the developers until it is decided that it is a good idea and that it can be implemented. At that point, as with any implementation, some excited fool (probably me) will no doubt find him or herself letting the cat out of the bag on the Forum. That is a very good thing. At that point, the users can weigh in, as their input at that point is just what is needed. Optional then/do's wouldn't have seen the light of day on the Forum. Another good thing. > On EUforum we have not went into source level details. This is subjective. When I see multiple implementations of a construct in a single post, I see the same thing. Little arrow diagrams. MIGO. > There have been email > conversations amongst developers w/source level details, we have not done any > of that on the forum. See above. Egads. > Now, back to discussion. The discussion on the forum has been flying, but we > are on the brink of a brand new release. The forum will always increase in > activity > during these times. We do not want a new user coming to see Euphoria and look > at the user forum to find the last post was 3 days ago, or that there is 2 > posts > today, 3 posts yesterday, the prior day no posts, etc... If you can conjecture that the developer traffic will decline at some point in the future, I can conjecture that a new version with additional features will increase the language's reach and therefore increase the user forum traffic. I'd rather plan for future expansion and be disappointed than not do so and suffer the consequences of a damaged reputation brought about by being described as "unweildly". Mike
16. Re: Euphoria Developers Group Discussion
- Posted by "Euler German" <eulerg at gmail.com> May 15, 2008
- 1027 views
> On 15 May 2008 at 11:21, Jeremy Cowgar wrote (maybe snipped): > c.k.lester wrote: > > > > What developers should do is discuss among themselves implementation > > details, then present a vote to the community... MAYBE. As above, > > most changes can be done without consulting the general > > population... and I don't think they'll care! It's just another > > feature they can decide to use or not use. > > Is this what users want? > I hope not. The main target of any product is its user base. May I suggest this willing group of developers get some "moderation", just to keep the train on rails, and avoid that "MAYBEs" fell from where they stand? Please? Euler -- _ _| euler f german _| sete lagoas, mg, brazil _| efgerman{AT}gmail{DOT}com
17. Re: Euphoria Developers Group Discussion
- Posted by Mike777 <anon4321 at ?mai?.com> May 15, 2008
- 1021 views
Euler German wrote: > > > On 15 May 2008 at 11:21, Jeremy Cowgar wrote (maybe snipped): > > > c.k.lester wrote: > > > > > > What developers should do is discuss among themselves implementation > > > details, then present a vote to the community... MAYBE. As above, > > > most changes can be done without consulting the general > > > population... and I don't think they'll care! It's just another > > > feature they can decide to use or not use. > > > > Is this what users want? > > > > I hope not. The main target of any product is its user base. May I > suggest this willing group of developers get some "moderation", just > to keep the train on rails, and avoid that "MAYBEs" fell from where > they stand? Please? Why do you conclude that developer actions will be completely independent of user input? Mike
18. Re: Euphoria Developers Group Discussion
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.?om> May 15, 2008
- 1022 views
c.k.lester wrote: > > Changes to the interpreter do not require community input except when those > changes will introduce breaks with old code or will in some way harm the > current performance of Euphoria. Otherwise, it's just another feature they > can decide to use or not use. > > What developers should do is discuss among themselves implementation details, > then present a vote to the community... MAYBE. As above, most changes can > be done without consulting the general population... and I don't think they'll > care! It's just another feature they can decide to use or not use. I think part of the reason we look for validation from the community is that the development model is so open. No one is really in charge at this point. In theory, Rob's opinion would likely weigh more heavily than others, but he's certainly not a dictator (benevolent or otherwise) at this point. When a change is proposed that will have large effects upon the way we code in euphoria, I'm nervous about imposing my views on others without getting feedback first. I think one thing that most of us want to preserve (even while improving the language) is to preserve what we like about euphoria. Of course, this is different for each person. Adding a function here or there is relatively trivial in impact compared to modifying the include system, or changing other syntax. Matt
19. Re: Euphoria Developers Group Discussion
- Posted by Mike777 <anon4321 at ?mail.c?m> May 15, 2008
- 1041 views
Matt Lewis wrote: > > c.k.lester wrote: > > > > Changes to the interpreter do not require community input except when those > > changes will introduce breaks with old code or will in some way harm the > > current performance of Euphoria. Otherwise, it's just another feature they > > can decide to use or not use. > > > > What developers should do is discuss among themselves implementation > > details, > > then present a vote to the community... MAYBE. As above, most changes can > > be done without consulting the general population... and I don't think > > they'll > > care! It's just another feature they can decide to use or not use. > > I think part of the reason we look for validation from the community is that > the development model is so open. No one is really in charge at this point. > In theory, Rob's opinion would likely weigh more heavily than others, but > he's certainly not a dictator (benevolent or otherwise) at this point. > > When a change is proposed that will have large effects upon the way we code > > in euphoria, I'm nervous about imposing my views on others without getting > feedback first. I think one thing that most of us want to preserve (even > while improving the language) is to preserve what we like about euphoria. > Of course, this is different for each person. Adding a function here or > there is relatively trivial in impact compared to modifying the include > system, or changing other syntax. I don't see the bifurcated system as a prescription for avoiding user input on any specific decision. The fact that you feel this way is a very, very good thing and will work to ensure that even if there is 100% consensus amongst the developers somebody will no doubt suggest that it should at least be mentioned on the Forum. Good. Mike
20. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ?klester.?om> May 15, 2008
- 1019 views
Matt Lewis wrote: > c.k.lester wrote: > > Changes to the interpreter do not require community input except when those > > changes will introduce breaks with old code or will in some way harm the > > current performance of Euphoria. Otherwise, it's just another feature they > > can decide to use or not use. > > > > What developers should do is discuss among themselves implementation > > details, > > then present a vote to the community... MAYBE. As above, most changes can > > be done without consulting the general population... and I don't think > > they'll > > care! It's just another feature they can decide to use or not use. > > I think part of the reason we look for validation from the community is that > the development model is so open. And my argument is that "the community" isn't very vocal, ever. You have a core base of developers who do want to voice their input, but I would say 95% of Euphoria users are happy with the direction Euphoria is going. Otherwise, we'd hear about it. The other possibility is that we're the only ones using Euphoria, and that's why there's so little input. :) > When a change is proposed that will have large effects upon the way we code > in euphoria, I'm nervous about imposing my views on others without getting > feedback first. I somewhat agree, but not really. Generally, the changes the developers agree on will be double-plus-good for Euphoria. Now, on code breakage, I did say a population query would probably be good. But for changes like enum, it doesn't break code and it makes Euphoria coding easier. PLUS, you don't even have to use it. Stick with the old way if you want. The point being, no negatives and only positives means we don't need to consult the other 95% of the people who won't care anyway.
21. Re: Euphoria Developers Group Discussion
- Posted by CChris <christian.cuvier at agricul?u?e.gouv.fr> May 15, 2008
- 1025 views
- Last edited May 16, 2008
c.k.lester wrote: > > Matt Lewis wrote: > > c.k.lester wrote: > > > Changes to the interpreter do not require community input except when > > > those > > > changes will introduce breaks with old code or will in some way harm the > > > current performance of Euphoria. Otherwise, it's just another feature they > > > can decide to use or not use. > > > > > > What developers should do is discuss among themselves implementation > > > details, > > > then present a vote to the community... MAYBE. As above, most changes can > > > be done without consulting the general population... and I don't think > > > they'll > > > care! It's just another feature they can decide to use or not use. > > > > I think part of the reason we look for validation from the community is that > > the development model is so open. > > And my argument is that "the community" isn't very vocal, ever. You have a > core base of developers who do want to voice their input, but I would say > 95% of Euphoria users are happy with the direction Euphoria is going. > Otherwise, we'd hear about it. > You know, we are such a small group of vocal people here. There will always be disagreement for the sake of disagreeing. Just have some random reading of this list for the past 18 months, and see how productive it had got. Keep pushing hard, Jeremy. > The other possibility is that we're the only ones using Euphoria, and that's > why there's so little input. :) > I have exactly zero idea of how we forum posters are representative of the user base at large. I don't want to look pessimistic, but I wouldn't be surprised of you were almost right. > > When a change is proposed that will have large effects upon the way we code > > in euphoria, I'm nervous about imposing my views on others without getting > > feedback first. > > I somewhat agree, but not really. Generally, the changes the developers > agree on will be double-plus-good for Euphoria. Now, on code breakage, I > did say a population query would probably be good. But for changes like > enum, it doesn't break code and it makes Euphoria coding easier. PLUS, you > don't even have to use it. Stick with the old way if you want. The point > being, no negatives and only positives means we don't need to consult the > other 95% of the people who won't care anyway. Did you notice how many improvements that would have broken zero code, because they were giving meaning to something currently illegal, were brought down because "name is not right", "one keyword more is too much" and such? A lot. CChris
22. Re: Euphoria Developers Group Discussion
- Posted by Matt Lewis <matthewwalkerlewis at gm?i?.com> May 15, 2008
- 1023 views
- Last edited May 16, 2008
Mike777 wrote: > > I don't see the bifurcated system as a prescription for avoiding user input > on any specific decision. The fact that you feel this way is a very, very > good thing and will work to ensure that even if there is 100% consensus > amongst the developers somebody will no doubt suggest that it should at > least be mentioned on the Forum. Good. Personally, I like the idea of having a developers forum or mailing list, but I'd probably only use it for talking about implementation details that most people wouldn't want to hear. Just like I tend to take conversations about other projects off-line. For example, I don't think that most people are interested in the finer points of crafting a Watcom makefile. Or even hacking on the front end, which is all euphoria. Matt
23. Re: Euphoria Developers Group Discussion
- Posted by Jeremy Cowgar <jeremy at cowgar.c??> May 15, 2008
- 1015 views
- Last edited May 16, 2008
Matt Lewis wrote: > > Mike777 wrote: > > > > I don't see the bifurcated system as a prescription for avoiding user input > > on any specific decision. The fact that you feel this way is a very, very > > good thing and will work to ensure that even if there is 100% consensus > > amongst the developers somebody will no doubt suggest that it should at > > least be mentioned on the Forum. Good. > > Personally, I like the idea of having a developers forum or mailing list, but > I'd probably only use it for talking about implementation details that most > people wouldn't want to hear. Just like I tend to take conversations about > other projects off-line. > > For example, I don't think that most people are interested in the finer > points of crafting a Watcom makefile. Or even hacking on the front end, > which is all euphoria. > > Matt Agreed. Matt, should I set one up on SF for that use? Anyone who wants to listen to use to chat about the horrors of making a Watcom makefile work on DOS, Win98 and XP/Vista are free to join. I also think it would be OK for us to discuss *possible* improvements on the developer list. For example, I may suggest "Hey, let's get rid of the include statement and just make everyone write it all in a big file. That would be faster for the parser." ... Immediately I'd be shot down on the developer list. No need to panic the userbase about that! But if we propose a function, syntax, etc... and the majority of the developers think its a good idea, we can solicit EUforum for input. -- Jeremy Cowgar http://jeremy.cowgar.com
24. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ckles?er.c?m> May 15, 2008
- 1026 views
- Last edited May 16, 2008
CChris wrote: > Did you notice how many improvements that would have broken zero code, because > they were giving meaning to something currently illegal, were brought down > because > "name is not right", "one keyword more is too much" and such? A lot. Such is the dynamics of design by committee. :)
25. Re: Euphoria Developers Group Discussion
- Posted by Matt Lewis <matthewwalkerlewis at gm?il.com> May 15, 2008
- 1024 views
- Last edited May 16, 2008
CChris wrote: > > You know, we are such a small group of vocal people here. There will always > be disagreement for the sake of disagreeing. No there won't! Matt
26. Re: Euphoria Developers Group Discussion
- Posted by Derek Parnell <ddparnell at b?gpo?d.com> May 15, 2008
- 995 views
- Last edited May 16, 2008
c.k.lester wrote: > > CChris wrote: > > > Did you notice how many improvements that would have broken zero code, > > because > > they were giving meaning to something currently illegal, were brought down > > because > > "name is not right", "one keyword more is too much" and such? A lot. > > Such is the dynamics of design by committee. :) Before we accept this assertion, can we have some examples of what you are talking about Chris? -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
27. Re: Euphoria Developers Group Discussion
- Posted by ChrisBurch3 <crylex at ?m?il.com> May 15, 2008
- 1011 views
- Last edited May 16, 2008
Matt Lewis wrote: > > CChris wrote: > > > > You know, we are such a small group of vocal people here. There will always > > be disagreement for the sake of disagreeing. > > No there won't! > > Matt Tweaked the syntax Yes there Chris
28. Re: Euphoria Developers Group Discussion
- Posted by CChris <christian.cuvier at agr?culture.gou?.fr> May 16, 2008
- 1006 views
Derek Parnell wrote: > > c.k.lester wrote: > > > > CChris wrote: > > > > > Did you notice how many improvements that would have broken zero code, > > > because > > > they were giving meaning to something currently illegal, were brought down > > > because > > > "name is not right", "one keyword more is too much" and such? A lot. > > > > Such is the dynamics of design by committee. :) > > Before we accept this assertion, can we have some examples of what you are > talking > about Chris? > > -- > Derek Parnell > Melbourne, Australia > Skype name: derek.j.parnell - Structure field declarations - continue, select ... case - min, max and friends - [] desequence operator - sequence of <type> an many more, didn't keep a complete tally, being tired of the repeating pattern. CChris
29. Re: Euphoria Developers Group Discussion
- Posted by Matt Lewis <matthewwalkerlewis at g?ail?com> May 16, 2008
- 1024 views
CChris wrote: > > Derek Parnell wrote: > > > > c.k.lester wrote: > > > > > > CChris wrote: > > > > > > > Did you notice how many improvements that would have broken zero code, > > > > because they were giving meaning to something currently illegal, were > > > > brought down because > > > > "name is not right", "one keyword more is too much" and such? A lot. > > > > > > Such is the dynamics of design by committee. :) > > > > Before we accept this assertion, can we have some examples of what you are > > talking > > about Chris? > > - Structure field declarations This one certainly isn't about "name." There are some serious differences of opinion about how detailed this should be. > - continue, select ... case Could you point out where the name/keyword issue has stopped this? I thought everyone was in agreement about the implementation. Continue is already in there. We could still change the name easily enough. I also thought that we've basically agreed about the need for case, but not the details yet. Either way, your argument doesn't fit. > - min, max and friends There were debates about what sort of arguments, etc, this should take. > - [] desequence operator I don't recall arguments about this one... > - sequence of <type> There are serious performance issues here that I don't think were ever addressed. Plus serious disagreements about how it should behave. > an many more, didn't keep a complete tally, being tired of the repeating > pattern. Sorry, but unless you can find some real examples, I'm calling BS. C'mon, there were substantial disagreements about how most of these things should be implemented. It's too bad that we can't all agree, but that's life. Matt
30. Re: Euphoria Developers Group Discussion
- Posted by gshingles <gshingles at g?ail.com> May 16, 2008
- 1033 views
c.k.lester wrote: > > Mike777 wrote: > > > > > > With that said, I am strongly in favor of bifurcation. I don't agree with a separate developer forum in the form that seems to be developing. I think users of the language do need to be involved with the discussion of its features, development, and direction. I have looked through the source code for Euphoria but do not have the detailed understanding of how it all works. So I think Jeremy had it right when he said the developer's list (if needed) is more for "What does this block of code do?, How does this stuff work?" etc. But it is a conundrum I agree. Before running off and possibly ruining the momentum that this list has gathered I would like to propose a suggestion for the EUForum itself. What if each thread could be 'tagged' with a section? For example this thread is tagged "Development Organisation" or whatever, a thread on how to make a button change its text is tagged "Win32lib" A thread about the roadmap could be tagged 'Development' etc. etc. When new message is created, you tick the section(s) that apply. Or when replying to a message you change the tick boxes around if it's going off topic. In your preferences for the list you tick the sections you want to see (defaulting to all) When you see the list, you only see what you're interested in, and perhaps a message like "142 messages filtered". Old messages continue to expire to the archive, but perhaps maintain their section tag to enhance their searchability. What this means is that if you are not interested in seeing any developer stuff, or wxEuphoria examples, or off-topic quips they will be efficiently filtered. I'm not sure how this would affect RSS readers. This of course requires Rob's buy-in or whoever is maintaining the EUForum itself, and of course everyone's buy-in to tick the boxes. Gary
31. Re: Euphoria Developers Group Discussion
- Posted by gshingles <gshingles at ?ma?l.com> May 16, 2008
- 1036 views
c.k.lester wrote: > > Changes to the core, including standard libs. These are things that > newbs aren't interested in and could be overwhelmed by. What 'newbs'? I don't think I've seen more than about 10 new users posting in EUForum in the last three years? (I could be wrong?) Half the time a new name turns out to be an old-hand with a new email address, or just someone who has search out a better way and found Euphoria, ie someone interested in programming principles. Without detailed access logs to the forum, or a proper user survey, I don't think anyone is in a position to say how effective or ineffective 'this way' is. > Changes to the interpreter do not require community input except when those > changes will introduce breaks with old code or will in some way harm the > current performance of Euphoria. Otherwise, it's just another feature they > can decide to use or not use. I don't agree. Sure they can decide whether to use it or not, but if it has been implemented in an 'unusable' (or limited/inefficient) way, that decision will have already been made for them. > What developers should do is discuss among themselves implementation details, > then present a vote to the community... That seems a bit too ... democratic to me... in the negative sense of the word. The community needs to drive the development not make multiple choices about it; given the good graces of the developers who will actually get their hands dirty doing it, of course :) Gary
32. Re: Euphoria Developers Group Discussion
- Posted by Dan Moyer <danielmoyer at pro?i?y.net> May 16, 2008
- 1015 views
c.k.lester wrote: > > ChrisBurch2 wrote: > > c.k.lester wrote: > > > So, somebody set up a Euphoria Developers forum and those who care about > > > Euphoria development can join. > > Absolutey bang on the nail CK. A developers group should be split off. > > I nominate <a href="http://www.assembla.com/">http://www.assembla.com/</a> to > host the developer's group. :) > > It is faster than SourceForge and free. I don't know if it's as feature-rich, > but it looks like it has all we need. But you guys can look it up and compare. > I am using Assembla for BBCMF development. Or, just split THIS list into two lists, Support & Development, with either (or both combined) selectable at Euphoria Home. or, as a re-design IDEA, http://audacityteam.org/forum/index.php Dan
33. Re: Euphoria Developers Group Discussion
- Posted by c.k.lester <euphoric at ckl?st?r.com> May 16, 2008
- 994 views
gshingles wrote: > c.k.lester wrote: > > Changes to the interpreter do not require community input except when those > > changes will introduce breaks with old code or will in some way harm the > > current performance of Euphoria. Otherwise, it's just another feature they > > can decide to use or not use. > I don't agree. Sure they can decide whether to use it or not, but if it has > been implemented in an 'unusable' (or limited/inefficient) way, that decision > will have already been made for them. That's why I said "those changes that will introduce breaks with old code or will in some way harm the current performance..." It won't be implemented in an unusable/limited/inefficient way. > The community needs to drive the development... This has been tried and it fails. When asked for input, only a few people ever respond, if any. I'm saying gather those interested parties together and leave everybody else alone. I use PHP. I don't care about its development so I'm not part of that developers group. I'm sure there are many Euphoria users who feel the same about Euphoria. But I use Euphoria and I care what happens to it, so I would want to give my input and help guide its development.